Chapter 1. Overview

About Deploying Application-Centric Infrastructure Layer 4 to Layer 7 Services

Configuring Layer 4 to Layer 7 Services Using the GUI

About Service Graph Templates

Chapter 2. Importing a Device Package

About the Device Package

Installing a Device Package Using REST

Importing a Device Package Using the GUI

Chapter 3. Defining a Logical Device

About Device Clusters

About Managed Device Clusters

About Unmanaged Device Clusters

About Concrete Devices

Creating a Device Using the GUI

Creating a Device Using the NX-OS-Style CLI

Using an Imported Device Using the REST APIs

Importing a Device From Another Tenant Using the NX-OS-Style CLI

Using an Imported Device Using the Object Model CLI

Verifying the Import of a Device Using the GUI

Chapter 4. Configuring Connectivity to Devices

About In-Band Management for Devices

Configuring In-Band Management for Devices Using the GUI

Troubleshooting In-Band Management for Devices Using the GUI

Chapter 5. Selecting a Layer 4 to Layer 7 Device to Render a Graph

About Device (Logical Device) Contexts

Creating a Logical Device Context Using the GUI

Configuring a Device Selection Policy Using REST APIs

Creating a Device Context Using the REST APIs

Adding a Logical Interface in a Device Using the REST APIs

Configuring the Device Selection Policy Using the Object Model CLI

Chapter 6. Configuring a Service Graph

About Service Graphs

About Function Nodes

About Function Node Connectors

About Service Graph Connections

About Terminal Nodes

About Service Graph Template Configuration Parameters

Configuring Service Graph Templates Using the GUI

Creating a Service Graph Template Using the REST APIs

Configuring a Service Graph Using the NX-OS-Style CLI

Chapter 7. Configuring Route Peering

About Route Peering

Open Shortest Path First Policies

Border Gateway Protocol Policies

Selecting an L3extOut Policy for a Cluster

Route Peering End-to-End Flow

Cisco Application Centric Infrastructure Fabric Serving As a Transit Routing Domain

Configuring Route Peering Using the GUI

Creating a Static VLAN Pool Using the GUI

Creating an External Routed Domain Using the GUI

Creating an External Routed Network Using the GUI

Creating a Router Configuration Using the GUI

Creating a Service Graph Association Using the GUI

Configuring Route Peering Using the NX-OS-Style CLI

Troubleshooting Route Peering

Verifying the Leaf Switch Route Peering Functionality Using the CLI

Chapter 8. Configuring Direct Server Return

About Direct Server Return

Layer 2 Direct Server Return

About Deploying Layer 2 Direct Server Return with Cisco Application Centric Infrastructure

Supported Direct Server Return Configuration

Direct Server Return Architecture

Example XML POST of Direct Server Return for Static Service Deployment

Direct Server Return for Static Service Deployment

Direct Server Return for Static Service Deployment Logical Model

Direct Server Return for Service Graph Insertion

Direct Server Return Shared Layer 4 to Layer 7 Service Configuration

Configuring the Citrix Server Load Balancer for Direct Server Return

Configuring a Linux Server for Direct Server Return

Chapter 9. Configuring the Device and Chassis Manager

About Device Managers and Chassis Managers

Device Manager and Chassis Manager Behavior

Creating a Device Manager Using the GUI

Creating a Chassis Using the GUI

Example XML for Device Managers and Chassis Managers

Example XML for Creating the MDevMgr Object

Example XML for Associating an LDevVip Object With a DevMgr Object

Example XML for Creating the MChassis Object

Example XML for Creating the Chassis Object

Example XML for Associating an CDev Object With a Chassis Object

Device and Chassis Callouts

Example deviceValidate Callout for a Device

Example deviceAudit Callout for a Device

Example clusterAudit Callout for a Device

Example serviceAudit Callout for a Device

Example deviceValidate Callout for a Chassis

Example deviceAudit Callout for a Chassis

Example clusterAudit Callout for a Chassis

Example serviceAudit Callout for a Chassis

Chapter 10. Configuring Unmanaged Mode

About the Unmanaged Mode

About Managed and Unmanaged Logical Devices

About Managed and Unmanaged Function Nodes

About Layer 4 to Layer 7 Services Endpoint Groups

Using Static Encapsulation for a Graph Connector

Creating a Physical Device Using the NX-OS-Style CLI

Creating a High Availablity Cluster Using the NX-OS-Style CLI

Creating a Virtual Device Using the NX-OS-Style CLI

Example XML for the Unmanaged Mode

Example XML of Creating an Unmanaged LDevVip Object

Example XML of Creating an Unmanaged AbsNode Object

Example XML of Associating a Layer 4 to Layer 7 Service Endpoint Group with a Connector

Example XML of Using Static Encapsulation with a Layer 4 to Layer 7 Service Endpoint Group

Unmanaged Mode Behavior

Chapter 11. Configuration Parameters

Configuration Parameters Inside the Device Package Specification

Configuration Scope of a Device Package Specification

Example XML of Configuration Parameters Inside the Device Package

Configuration Parameters Inside An Abstract Function Profile

Configuration Scope of an Abstract Function Profile

Example XML POST for an Abstract Function Profile With Configuration Parameters

Configuration Parameters Inside an Abstract Function Node in a Service Graph

Example XML POST for an Abstract Function Node With Configuration Parameters

Configuration Parameters Inside Various Configuration MOs

Example XML POST for an Application EPG With Configuration Parameters

Parameter Resolution

Looking Up an MO During Parameter Resolution

About Role-Based Access Control Rule Enhancements

Role-Based Access Control Rule Architecture

Role-Based Access Control Rule System Flow

Chapter 12. Using a Service Graph Template

Associating Service Graph Templates with Contracts and EPGs Using the GUI

Creating a Service Graph Template Using the NX-OS-Style CLI

Configuring a Service Graph Template Using the Object Model CLI

Configuring a Service Graph Template Using the REST APIs

Creating a Security Policy Using the REST APIs

Chapter 13. Monitoring a Service Graph

Monitoring a Service Graph Instance Using the GUI

Monitoring Service Graph Faults Using the GUI

Resolving Service Graph Faults

Monitoring a Virtual Device Using the GUI

Monitoring Device Cluster and Service Graph Status Using the NX-OS-Style CLI

Monitoring Device Cluster and Service Graph Status Using the Object Model CLI

Chapter 14. Configuring Administrator Roles for Managing a Service Configuration

About Privileges

Configuring a Role for Device Management

Configuring a Role for Service Graph Template Management

Configuring a Role for Uploading Device Package

Configuring a Role for Exporting Devices

Chapter 15. Developing Automation

About the REST APIs

Examples of Automating Using the REST APIs

Chapter 16. Using the GUI

Deploying the Layer 4 to Layer 7 Services Using the GUI

Importing a Device Package Using the GUI

Creating a Function Profile Using the GUI

Using an Existing Function Profile to Create a New Function Profile Using the GUI

Creating a Layer 4 to Layer 7 Service Graph Template Using the GUI

Modifying a Device

Applying a Service Graph Template to Endpoint Groups Using the GUI

Preface

Audience

Document Conventions

Related Documentation

Documentation Feedback

Obtaining Documentation and Submitting a Service Request

Copyright Page

Chapter 1. Overview

- About Deploying Application-Centric Infrastructure Layer 4 to Layer 7 Services

- Configuring Layer 4 to Layer 7 Services Using the GUI

- About Service Graph Templates

About Deploying Application-Centric Infrastructure Layer 4 to Layer 7 Services

Traditionally, when you insert services into a network, you must perform a highly manual and complicated VLAN (Layer 2) or virtual routing and forwarding (VRF) instance (Layer 3) stitching between network elements and service appliances. This traditional model requires days or weeks to deploy new services for an application. The services are less flexible, operating errors are more likely, and troubleshooting is more difficult. When an application is retired, removing a service device configuration, such as firewall rules, is difficult. Scale out/scale down of services that is based on the load is also not feasible.

Although VLAN and virtual routing and forwarding (VRF) stitching is supported by traditional service insertion models, the Application Policy Infrastructure Controller (APIC) can automate service insertion while acting as a central point of policy control. The APIC policies manage both the network fabric and services appliances. The APIC can configure the network automatically so that traffic flows through the services. The APIC can also automatically configure the service according to the application's requirements, which allows organizations to automate service insertion and eliminate the challenge of managing the complex techniques of traditional service insertion.

You must perform the following tasks to deploy Layer 4 to Layer 7 services using the APIC:

1. Import the device package

Only the provider administrator can import the device package.

2. Configure a tenant

3. Register the device and the logical interfaces

This task also registers concrete devices and concrete interfaces, and configures concrete device parameters.

4. Configure device (logical device) parameters

5. Configure a Layer 3 network

6. Configure a bridge domain

7. Configure an application profile

8. Configure a physical domain or a VMM domain

For a VMM domain:

1. Configure VMM domain credentials

2. Configure a vCenter/vShield controller profile

9. Configure a VLAN pool

1. Configure an encapsulation block range

10. Configure a contract

11. Configure a management endpoint group (EPG)

12. Configure a service graph template

13. Select the default service graph template parameters from an application profile

14. Configure the service graph template parameters, if needed

15. Attach the service graph template to a contract

16. Configure additional configuration parameters

Note

Virtualized appliances can be deployed with VLANs as the transport between VMware ESX servers and leaf nodes, and can be deployed only with VMware ESX as the hypervisor.

Configuring Layer 4 to Layer 7 Services Using the GUI

Using the GUI, you can configure the Layer 4 to layer 7 services for the Application Policy Infrastructure Controller (APIC).

See Using the GUI for the procedures for configuring the services and service graph templates.

About Service Graph Templates

The Cisco Application Centric Infrastructure (ACI) allows you to define a sequence of meta-devices, such a firewall of a certain type followed by a load balancer of a certain make and version. This is called an service graph template, also known as a abstract graph. When a service graph template is referenced by a contract, the service graph template is instantiated by mapping it to concrete devices, such as the firewall and load balancers that are present in the fabric. The mapping happens with the concept of a "context". The "device context" is the mapping configuration that allows the ACI to identify which firewalls and which load balancers can be mapped to the service graph template. Another key concept is the "logical device", which represents the cluster of concrete devices. The rendering of the service graph template is based on identifying the suitable logical devices that can be inserted in the path that is defined by a contract.

The 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 graph templates identify the set of network or service functions that are needed by the application. Once 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 template. The APIC also automatically configures the network according to the needs of the service function that is specified in the service graph template, which does not require any change in the service device.

Chapter 2. Importing a Device Package

- About the Device Package

- Installing a Device Package Using REST

- Importing a Device Package Using the GUI

About the Device Package

The Application Policy Infrastructure Controller (APIC) requires a device package to configure and monitor service devices. A device package manages a single class of service devices and provides the APIC with information about the device and its capabilities. A device package is a zip file that contains the following parts:

Device specification

An XML file that defines the following:

- Device properties:

- Model—Model of the device.

- Vendor—Vendor of the device.

- Version—Software version of the device.

- Functions provided by a device, such as load balancing, content switching, and SSL termination.

- Interfaces and network connectivity information for each function.

- Device configuration parameters.

- Configuration parameters for each function.

Device script

A Python script that interacts with the device from the APIC. APIC events are mapped to function calls that are defined in the device script. A device package can contain multiple device scripts.

Function profile

Function parameters with default values that are specified by the vendor. You can configure a function to use these default values.

Device-level configuration parameters

A configuration file that specifies parameters that are required by a device. This configuration can be shared by one or more graphs using a device.

You can create a device package or it can be provided by a device vendor or Cisco.

Installing a Device Package Using REST

You can install a device package using an HTTP or HTTPS POST.

Install the device package.

- If HTTP is enabled on the Application Policy Infrastructure Controller (APIC) , the URL for the POST is as follows:

http://10.10.10.10/ppi/node/mo/.xml

- If HTTPS is enabled on the APIC, the URL for the POST is as follows:

https://10.10.10.10/ppi/node/mo/.xml

The message must have a valid session cookie.

For information about obtaining a cookie, see the Cisco APIC REST API User Guide.

The body of the POST should contain the device package being uploaded. Only one package is allowed in a POST.

Importing a Device Package Using the GUI

You import a device package using the GUI.

See Using the GUI for the procedure for importing a device package.

Chapter 3. Defining a Logical Device

- About Device Clusters

- About Concrete Devices

- Creating a Device Using the GUI

- Creating a Device Using the NX-OS-Style CLI

- Using an Imported Device Using the REST APIs

- Importing a Device From Another Tenant Using the NX-OS-Style CLI

- Using an Imported Device Using the Object Model CLI

- Verifying the Import of a Device Using the GUI

About Device Clusters

A device cluster (also known as a logical device) is one or more concrete devices that act as a single device. A device cluster has cluster (logical) interfaces, which describe the interface information for the device cluster. During service graph template rendering, function node connectors are associated with cluster (logical) interfaces. The Application Policy Infrastructure Controller (APIC) allocates the network resources (VLAN or Virtual Extensible Local Area Network [VXLAN]) for a function node connector during service graph template instantiation and rendering and programs the network resources onto the cluster (logical) interfaces.

The service graph template uses a specific device that is based on a device selection policy (called a logical device context) that an administrator defines.

An administrator can set up a maximum of two concrete devices in active-standby mode.

To set up a device cluster, you must perform the following tasks:

1. Connect the concrete devices to the fabric.

2. Assign the management IP address to the device cluster.

3. Register the device cluster with the APIC. The APIC validates the device using the device specifications from the device package.

- About Managed Device Clusters

- About Unmanaged Device Clusters

About Managed Device Clusters

A device cluster can be configured as a managed device cluster. In managed mode, the Application Policy Infrastructure Controller (APIC) programs the devices during graph instantiation using the configuration provided to the APIC by an APIC administrator. For a managed device cluster, the APIC requires the device package for managing the devices in the device cluster.

By default, a device cluster is configured as a managed device cluster.

The following settings are needed when a device cluster is configured as managed:

- Device package

- Connectivity information for the logical device (vnsLDevViP) and devices (CDev)-management IP address, credentials, and in-band connectivity information

- Information about supported function types (go-through, go-to)

- Information about context awareness (single context or multi-context)

The APIC needs to know the topology information (LIF, CIF) for the device cluster and devices. This information is needed so that the APIC can program the appropriate ports on the leaf, and the APIC can also use this information for troubleshooting wizard purposes. The APIC also needs to know the relation to DomP, which is used for allocating the encapsulation.

About Unmanaged Device Clusters

A device cluster can be configured as an unmanaged device cluster. For an unmanaged device cluster, the Application Policy Infrastructure Controller (APIC) allocates only the network resources for the service graph and program on only the fabric side during graph instantiation. This might be useful if your environment already has an existing orchestrator or a dev-op tool that programs the devices in a device cluster. In some other cases, the device package for the service appliance is not available. Unmanaged mode enables the APIC to work with service devices without needing to have a device package.

The APIC needs to know the topology information (LIF, CIF) for the device cluster and devices. This information is needed so that the APIC can program the appropriate ports on the leaf, and the APIC can also use this information for troubleshooting wizard purposes. The APIC also needs to know the relation to DomP, which is used for allocating the encapsulation.

About Concrete Devices

A concrete device has concrete interfaces. When a concrete device is added to a logical device, 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.

Creating a Device Using the GUI

You can connect to either a physical device or a virtual machine. The fields are slightly different depending the type to which you are connecting. When you connecting to a physical device, you specify the physical interface. When you connect to a virtual machine, you specify the VMM domain, the virtual machine, and the virtual interfaces. Additionally, you can select an unknown model, which allows you to manually configure the connections.

Before You Begin

- You must have configured a tenant.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose tenant_name > L4-L7 Services > L4-L7 Devices.

Step 4

In the Work pane, choose Actions > Create L4-L7 Devices.

Step 5

In the Create L4-L7 Devices dialog box, in the General section, complete the following fields:

Name

Description

Managed check box

Put a check in the box to create a managed device, or remove the check from the box to create an unmanaged device.

Name field

Enter a name for the device.

Service Type drop-down list

Choose the service type.

Device Type buttons

Choose the device type.

Physical Domain or VMM Domain drop-down list

Choose the physical domain or VMM domain.

Mode radio buttons

Choose the mode for the device.

Device Package drop-down list

(Only for managed devices) Choose the mode for the device.

Model drop-down list

(Only for managed devices) Choose the vendor-provided device package that you will use.

Step 6

(Only for managed devices) In the Connectivity section, complete the following fields:

Name

Description

APIC to Device Management Connectivity radio buttons

Choose the type of connectivity. Choose Out-of-Band when you are connecting to a device that is outside of the fabric or In-Band when you are connecting to a device through the fabric.

Step 7

(Only for managed devices) In the Credentials section, complete the following fields:

Name

Description

User Name field

Enter your user name.

Password field

Enter your password.

Confirm Password field

Enter your password again.

Step 8

In the Device 1 section, complete the following fields:

Name

Description

Management IP Address field

(Only for managed devices) Enter the management IP address of the device to which you are connecting.

Management Port field and drop-down list

(Only for managed devices) Enter the management port or choose a value from the drop-down list.

VM drop-down list

(Only for the virtual device type) Choose a virtual machine.

Chassis drop-down list

(Only for managed devices) Choose a chassis.

Step 9

In the Device Interfaces table, click the + button to add an interface and complete the following fields:

Name

Description

Name drop-down list

Choose the interface name.

VNIC drop-down list

(Only for the virtual device type) Choose a vNIC.

Path drop-down list

Choose a port, port channel, or virtual port channel to which the interface will connect.

Step 10

Click Update.

Step 11

(Only for an HA cluster) Complete the fields for each device.

Step 12

Complete the fields for the Cluster section.

Step 13

Click Next.
The Device Configuration page displays a list of possible features and parameters for the package you are using. You see a tab with the Basic parameters displayed and another tab All Parameters that displays all the available parameters with your device package. The basic parameters are included under All Parameters.

Step 14

In the Features section, choose the set of features that you want to use. The set of parameters changes depending on the specific package you are using and the specific feature you select.

Step 15

For the parameters of the chosen features, supply the values as follows:

1. Double-click in the field you want to modify.

2. Enter the required information in the fields that appear.

3. Click Update.

Step 16

Click Finish.

Creating a Device Using the NX-OS-Style CLI

You can connect to either a physical device or a virtual machine. When you connecting to a physical device, you specify the physical interface. When you connect to a virtual machine, you specify the VMM domain, the virtual machine, and the virtual interfaces.

Before You Begin

- You must have configured a tenant.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Add a Layer 4 to Layer 7 device cluster.

l4l7 cluster name cluster_name type cluster_type vlan-domain domain_name
[function function_type] [service service_type]

Parameter

Description

name

The name of the device cluster.

type

The type of the device cluster. Possible values are:

- virtual

- physical

vlan-domain

The domain to use for allocating the VLANs. The domain must be a VMM domain for virtual device and physical domain for physical device.

function

(Optional) The function type. Possible values are:

- go-to

- go-through

service

(Optional) The service type. This is used by the GUI to show the ADC- or firewall-specific icons and GUI. Possible values are:

- ADC

- FW

- OTHERS

Example:
For a physical device, enter:

apic1(config-tenant)# l4l7 cluster name D1 type physical vlan-domain phys
function go-through service ADC

For a virtual device, enter:

apic1(config-tenant)# l4l7 cluster name ADCCluster1 type virtual vlan-domain mininet

Step 4

Add one or more cluster devices in the device cluster.

cluster-device device_name [vcenter vcenter_name] [vm vm_name]

Parameter

Description

vcenter

(Only for a virtual device) The name of VCenter that hosts the virtual machine for the virtual device.

vm

(Only for a virtual device) The name of the virtual machine for the virtual device.

Example:
For a physical device, enter:

apic1(config-cluster)# cluster-device C1
apic1(config-cluster)# cluster-device C2

For a virtual device, enter:

apic1(config-cluster)# cluster-device C1 vcenter vcenter1 vm VM1
apic1(config-cluster)# cluster-device C2 vcenter vcenter1 vm VM2

Step 5

Add one or more cluster interfaces in the device cluster.

cluster-interface interface_name [vlan static_encap]

Parameter

Description

vlan

(Only for a physical device) The static encapsulation for the cluster interface. VLAN value must be between 1 to 4094.

Example:
For a physical device, enter:

apic1(config-cluster)# cluster-interface consumer vlan 1001

For a virtual device, enter:

apic1(config-cluster)# cluster-interface consumer

Step 6

Add one or more members in the cluster interface.

member device device_name device-interface interface_name

Parameter

Description

device

The name of the cluster device that must have been already added to this device cluster using cluster-device command.

device-interface

The name of the interface on the cluster device.

Example:

apic1(config-cluster-interface)# member device C1 device-interface 1.1

Step 7

Add an interface to a member.

interface {ethernet ethernet_port | port-channel port_channel_name [fex fex_ID] |
vpc vpc_name [fex fex_ID]} leaf leaf_ID

If you want to add a vNIC instead of an interface, then skip this step.

Parameter

Description

ethernet

(Only for an Ethernet or FEX Ethernet interface) The Ethernet port on the leaf where the cluster device is connected to Cisco Application Centric Infrastructure (ACI) fabric. If you are adding a FEX Ethernet member, specify both the FEX ID and the FEX port in the following format:

FEX_ID/FEX_port

For example:

101/1/23

The FEX ID specifies where the cluster device is connected to Fabric extender.

port-channel

(Only for a port channel or FEX port channel interface) The port channel name where the cluster device is connected to ACI fabric.

vpc

(Only for a virtual port channel or FEX virtual port channel interface) The virtual port channel name where the cluster device is connected to ACI fabric.

fex

(Only for a port channel, FEX port channel, virtual port channel, or FEX virtual port channel interface) The FEX IDs in a space-separated list that are used to form the port channel or virtual port channel.

leaf

The leaf IDs in a space-separated list where the cluster device is connected.

Example:
For an Ethernet interface, enter:

apic1(config-member)# interface ethernet 1/23 leaf 101
apic1(config-member)# exit

For a FEX Ethernet interface, enter:

apic1(config-member)# interface ethernet 101/1/23 leaf 101
apic1(config-member)# exit

For a port channel interface, enter:

apic1(config-member)# interface port-channel pc1 leaf 101
apic1(config-member)# exit

For a FEX port channel interface, enter:

apic1(config-member)# interface port-channel pc1 leaf 101 fex 101
apic1(config-member)# exit

For a virtual port channel interface, enter:

apic1(config-member)# interface vpc vpc1 leaf 101 102
apic1(config-member)# exit

For a FEX virtual port channel interface, enter:

apic1(config-member)# interface vpc vpc1 leaf 101 102 fex 101 102
apic1(config-member)# exit

Step 8

Add a vNIC to a member.

vnic "vnic_name"

If you want to add an interface instead of a vNIC, then see the previous step.

Parameter

Description

vnic

The name of the VNIC adapter on the virtual machine for the cluster-device. Enclose the name in double quotes.

Example:

apic1(config-member)# vnic "Network adapter 2"
apic1(config-member)# exit

Step 9

If you are done creating the device, exit the configuration mode.

Example:

apic1(config-cluster-interface)# exit
apic1(config-cluster)# exit
apic1(config-tenant)# exit
apic1(config)# exit

Using an Imported Device Using the REST APIs

The following REST API uses an imported device:

<polUni>
<fvTenant dn="uni/tn-tenant1" name="tenant1">
<vnsLDevIf ldev="uni/tn-mgmt/lDevVip-ADCCluster1"/>
<vnsLDevCtx ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any">
<vnsRsLDevCtxToLDev tDn="uni/tn-tenant1/lDevIf-[uni/tn-mgmt/lDevVip-ADCCluster1]"/>
<vnsLIfCtx connNameOrLbl="inside">
<vnsRsLIfCtxToLIf tDn="uni/tn-tenant1/lDevIf-[uni/tn-mgmt/lDevVip-ADCCluster1]/lDevIfLIf-inside"/>
<fvSubnet ip="10.10.10.10/24"/>
<vnsRsLIfCtxToBD tDn="uni/tn-tenant1/BD-tenant1BD1"/>
</vnsLIfCtx>
<vnsLIfCtx connNameOrLbl="outside">
<vnsRsLIfCtxToLIf tDn="uni/tn-tenant1/lDevIf-[uni/tn-mgmt/lDevVip-ADCCluster1]/lDevIfLIf-outside"/>
<fvSubnet ip="70.70.70.70/24"/>
<vnsRsLIfCtxToBD tDn="uni/tn-tenant1/BD-tenant1BD4"/>
</vnsLIfCtx>
</vnsLDevCtx>
</fvTenant>
</polUni>

Importing a Device From Another Tenant Using the NX-OS-Style CLI

You can import a device from another tenant for a shared services scenario.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Import the device.

l4l7 cluster import-from tenant_name device-cluster device_name

Parameter

Description

import-from

Name of the tenant from where to import the device.

device-cluster

Name of the device cluster to import from the specified tenant.

Example:

apic1(config-tenant)# l4l7 cluster import-from common device-cluster d1
apic1(config-import-from)# end

Using an Imported Device Using the Object Model CLI

The following commands use an imported device using the object model CLI:

# logical-device-context
cd '/aci/tenants/tenant1/l4-l7-services/device-cluster-selection-policies'
mocreate 'any' 'any' 'any'
cd 'any-any-any'
moset device-cluster 'tenants/tenant1/l4-l7-services/imported-device-clusters/[uni/tn-mgmt/lDevVip-ADCCluster1]'
moconfig commit

# vns-lifctx
cd '/aci/tenants/tenant1/l4-l7-services/device-cluster-selection-policies/any-any-any/logical-interface-contexts'
mocreate 'inside'
cd 'inside'
moset logical-interface 'uni/tn-tenant1/lDevIf-[uni/tn-mgmt/lDevVip-ADCCluster1]/lDevIfLIf-inside'
moset bridge-domain 'tenants/tenant1/networking/bridge-domains/tenant1BD1'
moconfig commit

# fv-subnet
cd '/aci/tenants/tenant1/l4-l7-services/device-cluster-selection-policies/any-any-any/logical-interface-contexts/inside/subnets'
mocreate '10.10.10.10/24'
moconfig commit

# vns-lifctx
cd '/aci/tenants/tenant1/l4-l7-services/device-cluster-selection-policies/any-any-any/logical-interface-contexts'
mocreate 'outside'
cd 'outside'
moset logical-interface 'uni/tn-tenant1/lDevIf-[uni/tn-mgmt/lDevVip-ADCCluster1]/lDevIfLIf-outside'
moset bridge-domain 'tenants/tenant1/networking/bridge-domains/tenant1BD4'
moconfig commit

# fv-subnet
cd '/aci/tenants/tenant1/l4-l7-services/device-cluster-selection-policies/any-any-any/logical-interface-contexts/outside/subnets'
mocreate '70.70.70.70/24'
moconfig commit

# logical-device-consumer
cd '/aci/tenants/tenant1/l4-l7-services/imported-device-clusters'
mocreate 'uni/tn-mgmt/lDevVip-ADCCluster1'
cd '[uni--tn-mgmt--lDevVip-ADCCluster1]'
moset faultcode '0'
moconfig commit

Verifying the Import of a Device Using the GUI

You can use the GUI to verify that a device was imported successfully.

Step 1

On the menu bar, click the TENANTS tab. The Tenant window appears.

Step 2

On the submenu bar, click the name of the tenant for which you want to import devices.

Step 3

In the Navigation pane, expand the tenant's branch.

Step 4

Expand the L4-L7 Services branch.

Step 5

Expand the Imported Devices branch.

Step 6

Choose the appropriate device. The device information appears in the Work pane.

Chapter 4. Configuring Connectivity to Devices

- About In-Band Management for Devices

- Configuring In-Band Management for Devices Using the GUI

- Troubleshooting In-Band Management for Devices Using the GUI

About In-Band Management for Devices

The Cisco Application Centric Infrastructure (ACI) provides a mechanism for managing devices within each tenant in-band through the Cisco Application Centric Infrastructure (ACI) fabric. This configuration option provides device management connectivity without requiring the management IP addresses used on devices to be routable within the infra tenant and mgmt tenant.

Note

This feature is separate from in-band management for the ACIs and fabric nodes. In-band management for the fabric is not required for you to manage devices in-band.

In-band management communication between the ACIs and devices is enabled by configuring unique IP addresses on the ACIs. The IP addresses are known as controller endpoints. These IP addresses are not actually configured on the ACI interfaces, but instead are used in conjunction with Network Address Translation (NAT) to establish management communication with the devices. The NAT addresses that are used by the ACIs are automatically selected by the ACI and fall within the 169.254.0.0/16 address range.

In addition, each device management IP address is presented to the ACIs as a translated IP address. This translated address is referred to as the mapped host address.

The following figure depicts the address translation between the ACI and the devices:

Network Address Translation Between the ACI and the Devices

Configuring In-Band Management for Devices Using the GUI

You can configure in-band management for devices using the GUI.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose tenant_name > L4-L7 Services > L4-L7 Devices.

Step 4

In the Work pane, choose Actions > Create L4-L7 Devices

Step 5

In the Create L4-L7 Devices dialog box, fill in the fields as required, except as specified below:

1. For the APIC to Device Management Connectivity radio buttons, choose In-Band.

2. In the EPG drop-down list, choose Create Management EPG.

Step 6

In the Create Management EPG dialog box, fill in the fields as required, except as specified below:

1. In the Application Profile drop-down list, choose an existing application profile where the EPG will reside. Optionally, create a new application profile by choosing Create Application Profile.
If you create a new application profile, leave the EPG section and Contracts section blank.

2. In the Name field, enter a name for the management EPG.

3. In the Bridge Domain drop-down list, choose a domain.

4. In the Domains section, add a domain profile.

5. In the Reserved IP addresses for APICs section, click + to create a new IP address pool.

Step 7

In the Create IP Address Pool dialog box, fill in all of the fields and click OK.
The IP address pool defines the controller endpoint addresses. The IP addresses in the pool are the IP addresses that the devices will see as the Application Policy Infrastructure Controller (APIC) IP addresses.

If the address range that you defined for the controller endpoints is not part of the same subnet as the management IP addresses that you defined for the devices, you must define a subnet under the management EPG bridge domain that provides a next-hop gateway for the devices to reach the controller endpoints.

Step 8

In the Create Management EPG dialog box, click Submit. The domain name for the management EPG should now be populated.

Step 9

In the Create L4-L7 Devices dialog box, complete the device setup. Be sure to include the management interface in the configuration of the interfaces.

Troubleshooting In-Band Management for Devices Using the GUI

If you chose an existing endpoint group (EPG) as the management EPG for the devices, you must manually add the management IP address pools and controller management policies. You can add these using the GUI.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose tenant_name > Application Profiles > application_profile_name > Application EPGs > EPG_name > L4/L7 IP Address Pool.

Step 4

In the Work pane, choose Actions > Create Address Pool.

Step 5

In the Create IP Address Pool dialog box, fill in the fields as required.
This adds the management IP address pool.

Step 6

In the Navigation pane, choose tenant_name > L4-L7 Services > Inband Management Configuration for L4-L7 devices.

Step 7

In the Work pane, in the Controller Management Policies section, click + and fill in the fields as follows:

1. In the Private Networks drop-down list, choose a private network.

2. In the Address Pool drop-down list, choose the pool that you just created.

Step 8

Click Update.
This adds the controller management policy.

Chapter 5. Selecting a Layer 4 to Layer 7 Device to Render a Graph

- About Device (Logical Device) Contexts

- Creating a Logical Device Context Using the GUI

- Configuring a Device Selection Policy Using REST APIs

- Configuring the Device Selection Policy Using the Object Model CLI

About Device (Logical Device) Contexts

A device can be selected based on a contract name, a graph name, or the function node name inside the graph. After you create a device, you can create a device context, which provides a selection criteria policy for a device.

A device context specifies the policy for selecting a device for a service graph template. This allows an administrator to have multiple device and then be able to use them for different service graph templates. For example, an administrator can have a device that has high-performance ADC appliances and another device that has lower-performance ADC appliances. Using two different device contexts, one for the high-performance ADC device and the other for the low-performance ADC device, the administrator can select the high-performance ADC device for the applications that require higher performance and select the low-performance ADC devices for the applications that require lower performance.

Creating a Logical Device Context Using the GUI

If you did not use the Apply L4-L7 Service Graph Template To EPGs wizard to apply the service graph template, you might need to configure a logical device context, which is also known as a logical device selection policy. The logical device context instructs Cisco Application Centric Infrastructure (ACI) about which firewall or load balancer device to use to render a graph.

If you used the Apply L4-L7 Service Graph Template To EPGs wizard to apply the service graph template, then a logical device context was configured automatically and you do not need to configure one manually.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose Tenant tenant_name > L4-L7 Services > Devices Selection Policies.

Step 4

In the Work pane, choose Actions > Create Logical Device Context.

Step 5

In the Create Logical Device Context dialog box, fill in the fields as required, except as specified below:

1. In the Service Type drop-down list, choose the contract for the logical device context. If you do not want to use the contract name as part of the criteria for using a device, choose any.

2. In the Graph Name drop-down list, choose the graph for the logical device context. If you do not want to use the graph name as part of the criteria for using a device, choose any.

3. In the Node Name drop-down list, choose the node for the logical device context. If you do not want to use the node name as part of the criteria for using a device, choose any.

Step 6

In the Cluster Interface Contexts section, click + to add a cluster interface context.

- Connector Name—The name of the connector in the service graph template.

- Logical Interface—The logical interface to use for the connector that is specified in the logical interface context.

- Bridge Domain—The bridge domain that is specified in the logical interface context.

- Subnets—The subnet to configure on the logical interfaces when the service graph template is instantiated.

Step 7

Click Submit.

Configuring a Device Selection Policy Using REST APIs

You can use the REST APIs to configure a device selection policy.

- Creating a Device Context Using the REST APIs

- Adding a Logical Interface in a Device Using the REST APIs

Creating a Device Context Using the REST APIs

The following REST API creates a device context:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vnsLDevCtx ctrctNameOrLbl="webCtrct" graphNameOrLbl="G1" nodeNameOrLbl="Node1">
<vnsRsLDevCtxToLDev tDn="uni/tn-acme/lDevVip-ADCCluster1"/>

<!-- The connector name C4, C5, etc.. should match the
Function connector name used in the service graph template -->

<vnsLIfCtx connNameOrLbl=“C4">
<vnsRsLIfCtxToLIf tDn="uni/tn-acme/lDevVip-ADCCluster1/LIf-ext"/>
</vnsLIfCtx>
<vnsLIfCtx connNameOrLbl=“C5">
<vnsRsLIfCtxToLIf tDn="uni/tn-acme/lDevVip-ADCCluster1/LIf-int"/>
</vnsLIfCtx>
</vnsLDevCtx>
</fvTenant>
</polUni>

Adding a Logical Interface in a Device Using the REST APIs

The following REST API adds a logical interface in a device:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vnsLDevVip name="ADCCluster1">

<!-- The LIF name defined here (such as e.g., ext, or int) should match the
vnsRsLIfCtxToLIf ‘tDn' defined in LifCtx  -->

<vnsLIf name=“ext">

<vnsRsMetaIf tDn="uni/infra/mDev-Acme-ADC-1.0/mIfLbl-outside"/>
<vnsRsCIfAtt tDn="uni/tn-acme/lDevVip-ADCCluster1/cDev-ADC1/cIf-ext"/>
</vnsLIf>
<vnsLIf name=“int">
<vnsRsMetaIf tDn="uni/infra/mDev-Acme-ADC-1.0/mIfLbl-inside"/>
<vnsRsCIfAtt tDn="uni/tn-acme/lDevVip-ADCCluster1/cDev-ADC1/cIf-int"/>
</vnsLIf>
</vnsLDevVip>
</fvTenant>
</polUni>

Configuring the Device Selection Policy Using the Object Model CLI

The commands in this section configure a device selection policy using the object model CLI.

Note

When using the NX-OS-style CLI, the device selection policy is configured automatically; there are no equivalent NX-OS-style CLI commands.

# logical-device-context

cd '/aci/tenants/acme/l4-l7-services/device-cluster-selection-policies'
mocreate 'any' 'any' 'any'
cd 'any-any-any'
moset device-cluster 'tenants/acme/l4-l7-services/device-clusters/InsiemeCluster'
moconfig commit

# vns-lifctx

cd '/aci/tenants/acme/l4-l7-services/device-cluster-selection-policies/webCtrt-G1-Node1/logical-interface-contexts'
mocreate 'int'
cd 'int'
moset logical-interface 'tenants/acme/l4-l7-services/device-clusters/InsiemeCluster/logical-interfaces/int'
moset bridge-domain ‘tenants/acme/networking/bridge-domains/MySrvrBD'
moconfig commit

# vns-lifctx

cd '/aci/tenants/acme/l4-l7-services/device-cluster-selection-policies/webCtrt-G1-Node1/logical-interface-contexts'
mocreate ‘ext'
cd 'ext'
moset logical-interface ‘tenants/acme/l4-l7-services/device-clusters/InsiemeCluster/logical-interfaces/ext'
moset bridge-domain ‘tenants/acme/networking/bridge-domains/MyClntBD'
moconfig commit

Chapter 6. Configuring a Service Graph

- About Service Graphs

- About Function Nodes

- About Function Node Connectors

- About Service Graph Connections

- About Terminal Nodes

- About Service Graph Template Configuration Parameters

- Configuring Service Graph Templates Using the GUI

- Creating a Service Graph Template Using the REST APIs

- Configuring a Service Graph Using the NX-OS-Style CLI

About Service Graphs

A service graph is an ordered set of function nodes between a set of terminals, which identifies a set of network service functions that are required by an application. Service functions within a graph are automatically provisioned on a service device that is based on an application's requirements.

You can define a service graph by using the GUI, CLI, or the Application Policy Infrastructure Controller (APIC). Configuring a service device through the APIC does not require changes on a service device.

About Function Nodes

A function node represents a single service function. A function node has function node connectors, which represent the network requirement of a service function.

A function node within a service graph can require one or more parameters. The parameters can be specified by an endpoint group (EPG), an application profile, or a tenant context. Parameters can also be assigned at the time that you define a service graph. The parameter values can be locked to prevent any additional changes.

About Function Node Connectors

A function node connector connects a function node to the service graph and is associated with the appropriate bridge domain and connections based on the graph's connector's subset. Each connector is associated with a VLAN or Virtual Extensible LAN (VXLAN). Each side of a connector is treated as an endpoint group (EPG), and whitelists are downloaded to the switch to enable communication between the two function nodes.

About Service Graph Connections

A service graph connection connects one function node to another function node.

About Terminal Nodes

Terminal nodes connect a service graph with the contracts. You can insert a service graph for the traffic between two application endpoint groups (EPGs) by connecting the terminal node to a contract. Once connected, traffic between the consumer EPG and provider EPG of the contract is redirected to the service graph.

About Service Graph Template Configuration Parameters

A service graph template can have configuration parameters, which are specified by the device package. Configuration parameters can also be specified by an EPG, application profile, or tenant context. A function node within a service graph template can require one or more configuration parameters. The parameter values can be locked to prevent any additional changes.

When you configure a service graph template and specify the values of the configuration parameters, the Application Policy Infrastructure Controller (APIC) passes the parameters to the device script that is within the device package. The device script converts the parameter data to the configuration that is downloaded onto the device.

Configuring Service Graph Templates Using the GUI

You can configure the service graph templates using the GUI.

See Using the GUI for the procedure for configuring the service graph templates.

Creating a Service Graph Template Using the REST APIs

You can create a service graph template using the following REST API:

<polUni>
<fvTenant name="acme">
<vnsAbsGraph name="G1">
<vnsAbsTermNodeCon name="Input1">
<vnsAbsTermConn name="C1">
</vnsAbsTermConn>
</vnsAbsTermNodeCon>
<vnsAbsNode name="Node" funcType="GoTo">
<vnsRsDefaultScopeToTerm
tDn="uni/tn-acme/AbsGraph-G1/AbsTermNodeProv-Output1/outtmnl"/>
<vnsAbsFuncConn name="inside">
<vnsRsMConnAtt
tDn="uni/infra/mDev-Insieme-Generic-1.0/mFunc-SubnetFunc/mConn-external"/>
</vnsAbsFuncConn>
<vnsAbsFuncConn name="outside">
<vnsRsMConnAtt
tDn="uni/infra/mDev-Insieme-Generic-1.0/mFunc-SubnetFunc/mConn-internal"/>
</vnsAbsFuncConn>
<vnsAbsDevCfg>
<vnsAbsFolder key="oneFolder" name="f1">
<vnsAbsParam key="oneParam" name="p1" value="v1"/>
</vnsAbsFolder>
</vnsAbsDevCfg>
<vnsAbsFuncCfg>
<vnsAbsFolder key="folder" name="folder1" devCtxLbl="C1">
<vnsAbsParam key="param" name="param" value="value"/>
</vnsAbsFolder>
<vnsAbsFolder key="folder" name="folder2" devCtxLbl="C2">
<vnsAbsParam key="param" name="param" value="value"/>
</vnsAbsFolder>
</vnsAbsFuncCfg>
<vnsRsNodeToMFunc tDn="uni/infra/mDev-Insieme-Generic-1.0/mFunc-SubnetFunc"/>
</vnsAbsNode>
<vnsAbsTermNodeProv name="Output1">
<vnsAbsTermConn name="C6">
</vnsAbsTermConn>
</vnsAbsTermNodeProv>
<vnsAbsConnection name="CON1">
<vnsRsAbsConnectionConns
tDn="uni/tn-acme/AbsGraph-G1/AbsTermNodeCon-Input1/AbsTConn"/>
<vnsRsAbsConnectionConns tDn="uni/tn-acme/AbsGraph-G1/AbsNode-Node/AbsFConn-inside"/>
</vnsAbsConnection>
<vnsAbsConnection name="CON3">
<vnsRsAbsConnectionConns tDn="uni/tn-acme/AbsGraph-G1/AbsNode-Node/AbsFConn-outside"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-acme/AbsGraph-G1/AbsTermNodeProv-Output1/AbsTConn"/>
</vnsAbsConnection>
</vnsAbsGraph>
</fvTenant>
</polUni>

Configuring a Service Graph Using the NX-OS-Style CLI

You can configure a service graph using the NX-OS-style CLI.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Add a service graph.

l4l7 graph graph_name [contract contract_name]

Parameter

Description

graph

Name of the service graph.

contract

Name of the contract that is associated with this service graph instance. Specify the contract only if you want to create the service graph instance. You can simply configure a service graph (equivalent to the service graph template) without instantiating it.

Example:

apic1(config-tenant)# l4l7 graph G2 contract C2

Step 4

Add a node (service) in the service graph.

service node_name [device-cluster-tenant tenant_name] [device-cluster device_name] [mode deployment_mode]

Parameter

Description

service

The name of the service node to add.

device-cluster-tenant

The tenant from which to import the device cluster. Specify this only if the device-cluster is not in the same tenant in which the graph is being configured.

device-cluster

Name of the device cluster to use for this service node.

mode

The deployment mode. Possible values are:

- ADC_ONE_ARM—Specifies one-arm mode.

- ADC_TWO_ARM—Specifies two-arm mode.

- FW_ROUTED—Specifies routed (GoTo) mode.

- FW_TRANS—Specifies transparent (GoThrough) mode.

- OTHERS—Specifies any other deployment mode.

If the mode is not specified, then a deployment mode is not used.

Example:
The following example adds node N1 to the device cluster D4, which is from tenant t1:

apic1(config-graph)# service N1 device-cluster-tenant t1 device-cluster D4

The following example adds node N1 to the device cluster D4, which is from tenant t1, and uses the routed deployment mode:

apic1(config-graph)# service N1 device-cluster-tenant t1 device-cluster D4 mode FW_ROUTED

Step 5

Add the consumer connector.

connector connector_type [cluster-interface interface_type]

Parameter

Description

connector

The type of the connector in the service graph. Possible values are:

- provider

- consumer

cluster-interface

The type of the device cluster interface. Possible values are:

- provider

- consumer

Do not specify this parameter if you are a service graph template in tenant Common.

Example:

apic1(config-service)# connector consumer cluster-interface consumer

Step 6

Configure the bridge domain for the connectors by specifying the bridge domain information and tenant where the bridge domain is present.

bridge-domain tenant tenant_name name bridge_domain_name

Parameter

Description

tenant

Tenant that owns the bridge domain. You can only specify a bridge domain from same tenant or tenant Common. For example if you are in tenant t1, then you cannot specify the bridge domain from tenant t2.

name

Name of the bridge domain.

Example:

apic1(config-connector)# bridge-domain tenant t1 name bd2

Step 7

(Optional)Configure the direct server return (DSR) virtual IP address (VIP) for the connector.

dsr-vip ip_address

If you specify the DSR VIP, the Application Policy Infrastructure Controller (APIC) does not learn the VIP.

Parameter

Description

dsr-vip

The virtual IP address of the DSR for the connector.

Example:

apic1(config-connector)# dsr-vip 192.168.10.100

Step 8

Configure connections for the consumer and provider and exit the service graph configuration mode.

connection connection_name {terminal terminal_type service node_name connector connector_type} |
{intra_service service1 node_name connector1 connector_type service2 node_name connector2 connector_type}
exit

Parameter

Description

connection

The name of the connection.

terminal

Connects a service node to the terminal. Specifies the type of the terminal. Possible values are:

- provider

- consumer

service

service1

service2

The name of the service node to add. service is used only with terminal. service1 and service2 are used only with intra_service.

connector

connector1

connector2

The type of the connector. Possible values are:

- provider

- consumer

connector is used only with terminal. connector1 and connector2 are used only with intra_service.

intra_service

Connects a service node to another node.

Example:
The following example configures the connections of a single node graph:

apic1(config-graph)# connection CON1 terminal consumer service N1 connector consumer
apic1(config-graph)# connection CON2 terminal provider service N2 connector provider
apic1(config-graph)# exit

The following example configures the connections of a two node graph:

apic1(config-graph)# connection CON1 terminal consumer service N1 connector consumer
apic1(config-graph)# connection CON2 intra_service service1 N1 connector1 provider service2 N2 connector2 consumer
apic1(config-graph)# connection CON3  terminal provider service N2 connector provider
apic1(config-graph)# exit

Step 9

Exit the configuration mode.

Example:

apic1(config-tenant)# exit
apic1(config)# exit

Chapter 7. Configuring Route Peering

- About Route Peering

- Open Shortest Path First Policies

- Border Gateway Protocol Policies

- Selecting an L3extOut Policy for a Cluster

- Route Peering End-to-End Flow

- Cisco Application Centric Infrastructure Fabric Serving As a Transit Routing Domain

- Configuring Route Peering Using the GUI

- Configuring Route Peering Using the NX-OS-Style CLI

- Troubleshooting Route Peering

About Route Peering

Route peering is a special case of the more generic Cisco Application Centric Infrastructure (ACI) fabric as a transit use case, in which route peering enables the ACI fabric to serve as a transit domain for Open Shortest Path First (OSPF) or Border Gateway Protocol (BGP) protocols. A common use case for route peering is route health injection, in which the server load balancing virtual IP is advertised over OSPF or internal BGP (iBGP) to clients that are outside of the ACI fabric. You can use route peering to configure OSPF or BGP peering on a service device so that the device can peer and exchange routes with the ACI leaf node to which it is connected.

The following protocols are supported for route peering:

- OSPF

- OSPFv3

- iBGPv4

- iBGPv6

- Static routes

The following figure shows how route peering is commonly deployed:

Common Route Peering Topology

As shown in the figure, a Web server's public IP address is advertised to an external router through a firewall by deploying a service graph with route peering configured. You must deploy OSPF routing policies on each leg of the firewall. This is typically done by deploying l3extOut policies. This enables the Web server reachability information to be advertised over OSPF through the firewall to the border leaf and to the external router.

Route distribution between leaves in the fabric is internally accomplished over Multi-Protocol Border Gateway Protocol (MP-BGP).

For a more detailed example of the route peering topology, see Route Peering End-to-End Flow.

For more information about configuring l3extOut policies, see the Cisco Application Centric Infrastructure Fundamentals Guide.

Note

Point-to-point non-broadcast mode is not supported on an Adaptive Security Appliance (ASA). You must remove the point-to-point non-broadcast mode configuration from the Application Policy Infrastructure Controller (APIC) if the configuration exists.

Open Shortest Path First Policies

To configure route peering, you must first create one or more l3extOut policies and deploy them on the fabric leaf nodes where the service device is connected. These l3extOut policies specify the Open Shortest Path First (OSPF) parameters that you must enable on the fabric leaf. The policies are very similar to the l3extOut policies that are used for external communication. The following figure illustrates the route peering object relations.

OSPF Route Peering Object Relations

1. vnsLDevCtx—Device selection policy.

2. l3extOut—Contains all OSPF policies for a single area.

3. l3extRouteTagPol—Every context used by route peering needs a unique route tag to avoid OSPF loops. The OSPF routes that are learned from one leg will not be learned on the other leg unless the route tags are different.

4. ospfIfPol—OSPF per interface policy.

5. ospfExtP—OSPF per area policy.

6. l3extLNodeP/l3extLIfP—The nodes or ports on which this l3extOut is deployed.

7. l3extSubnet—Subnets to export from or import into the fabric.

8. l3extInstP—Prefix-based EPG.

Two example l3extOut policies, OspfExternal and OspfInternal, are shown below. These policies are deployed on the external and internal legs of the firewall device in Figure 1. The l3extOut policy specifies one or more prefix-based EPGs (l3extInstP), which control how traffic is classified by the fabric leaf and also how routes are imported from and exported to the service device. The l3extOut policy contains the OSPF per-area policy (ospfExtP) and one or more OSPF interface policies (ospfIfPol) that are specified under it.

The following example shows an OSPF area with area-Id being configured with a value of "100":

<ospfExtP areaId="100" areaType="regular" areaCtrl="redistribute"/>

The area type is set to "regular" and the area control attribute is set to "redistribute".

The OSPF interface policy specifies one or more OSPF interface timers:

<ospfIfPol name="ospfIfPol" ctrl="mtu-ignore" nwT="bcast" xmitDelay="1" helloIntvl="10"
deadIntvl="40" status="created,modified"/>

If default timers are fine, then you do not need to specify this policy. This policy allows certain timers to be modified from default values and is associated with one or more interfaces by using the following relation:

<13extRsPathL3OutAtt tDn="topology/pod-l/paths-101/pathep-[eth1/25]" ifInstT="ext-svi"
encap="vlan-3844" addr="30.30.30.100/28" mtu="1500"/>

The attributes of the 13extRsPathL3OutAtt relation are as follows:

- ifInstT—The logical interface type, which is typically "ext-svi".

- encap—You must specify a VLAN encapsulation when creating this interface. The encapsulation is pushed to the service device.

- addr— The IP address of the SVI interface that was created on the fabric leaf where this l3extOut is deployed.

The following policy controls where the l3extOut policy is deployed:

<13extNodeP name="bLeaf-101">
<13extRsNodeL30utAtt tDn="topology/pod-l/node-101" rtrId="180.0.0.11"/>
<13extLIfP name="portlf">
<13extRsPathL30utAtt tDn="topology/pod-1/paths-101/pathep-teth1/251"
ifInstT="ext-svi" encap="vlan-3844" addr="30.30.30.100/28" mtu="1500"/>
<ospfIfP authKey="tecom" authType="md5" authKeyId='1'>
<ospfRslfPol tnOspfIfPolName="ospfIfPol"/>
</ospflfP>
</13extLIfP>
</13extLNodeP>

The l3extOut policy must be deployed to the same leaf ports to which the service device is connected.

The scope=import-security attribute does the following things:

- Controls the flow of traffic in the data plane

- Acts as a directive to the external device to advertise this route

Note

For route peering to work correctly, the l3extRsPathL3OutAtt relation must point to the same fabric destination as the RsCIfPathAtt relation under the vnsCDev that represents the device.

OspfExternal Policy

<polUni>
<fvTenant name="common">
<fvCtx name="commonctx">
<fvRsCtxToExtRouteTagPol tnL3extRouteTagPolName="myTagPol"/>
</fvCtx>
<l3extRouteTagPol tag="212" name="myTagPol"/>
<l3extOut name="OspfExternal" status="created,modified">
<l3extLNodeP name="bLeaf-101">
<l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="180.0.0.8/28"/>
<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/23]"
ifInstT="ext-svi" encap="vlan-3843" addr="40.40.40.100/28" mtu="1500"/>
<ospfIfP authKey="tecom" authType="md5" authKeyId='1'>
<ospfRsIfPol tnOspfIfPolName="ospfIfPol"/>
</ospfIfP>
</l3extLIfP>
</l3extLNodeP>
<ospfExtP areaId="100" areaType="regular" areaCtrl="redistribute"/>
<l3extInstP name="ExtInstP">
<l3extSubnet ip="40.40.40.100/28" scope="import-security"/>
<l3extSubnet ip="10.10.10.0/24" scope="import-security"/>
</l3extInstP>
<l3extRsEctx tnFvCtxName="commonctx"/>
</l3extOut>
<ospfIfPol name="ospfIfPol" ctrl="mtu-ignore" nwT="bcast" xmitDelay="1" helloIntvl="10"
deadIntvl="40" status="created,modified"/>
</fvTenant>
</polUni>

<polUni>
<fvTenant name="tenant1">
<l3extRouteTagPol tag="213" name="myTagPol"/>
<fvCtx name="tenant1ctx1">
<fvRsCtxToExtRouteTagPol tnL3extRouteTagPolName="myTagPol"/>
</fvCtx>
<l3extOut name="OspfInternal" status="created,modified">
<l3extLNodeP name="bLeaf-101">
<l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="180.0.0.11"/>
<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/25]"
ifInstT="ext-svi" encap="vlan-3844" addr="30.30.30.100/28" mtu="1500"/>
<ospfIfP authKey="tecom" authType="md5" authKeyId='1'>
<ospfRsIfPol tnOspfIfPolName="ospfIfPol"/>
</ospfIfP>
</l3extLIfP>
</l3extLNodeP>
<ospfExtP areaId="100" areaType="regular" areaCtrl="redistribute"/>
<l3extInstP name="IntInstP">
<l3extSubnet ip="30.30.30.100/28" scope="import-security"/>
<l3extSubnet ip="20.20.20.0/24" scope="import-security"/>
</l3extInstP>
<l3extRsEctx tnFvCtxName="tenant1ctx1"/>
</l3extOut>
<ospfIfPol name="ospfIfPol" ctrl="mtu-ignore" nwT="bcast" xmitDelay="1" helloIntvl="10"
deadIntvl="40" status="created,modified"/>
</fvTenant>
</polUni>

The OspfExternalInstP policy specifies that prefixes 40.40.40.100/28 and 10.10.10.0/24 must be used for prefix-based endpoint association. The policy also instructs the fabric to export prefix 20.20.20.0/24 to the service device.

<13extInstP name="OspfExternalInstP">
<13extSubnet ip="40.40.40.100/28" scope="import-security"/>
<13extSubnet ip="10.10.10.0/24" scope="import-security"/>
<13extSubnet ip="20.20.20.0/24" scope="export"/>
</13extInstP>

The bleaf-101 policy controls where this l3extOut policy is deployed.

<l3extLNodeP name="bLeaf-101">
<l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="180.0.0.8/28"/>
<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/23]"
ifInstT="ext-svi" encap="vlan-3843" addr="40.40.40.100/28" mtu="1500"/>
<!-- <ospfIfP authKey="tecom" authType="md5" authKeyId='1'> -->
<ospfIfP>
<ospfRsIfPol tnOspfIfPolName="ospfIfPol"/>
</ospfIfP>
</l3extLIfP>
</l3extLNodeP>

You can deploy virtual services with route peering, although the l3extRsPathL3OutAtt validation with the vnsCIf object is not performed. The datapath will work only if the l3extOut object is deployed to the correct leaf to which the virtual service device is connected.

Border Gateway Protocol Policies

You can configure route peering using internal Border Gateway Protocol (iBGP) on the device’s external interface and static routes on the internal interface. You cannot configure iBGP on both the internal and external interfaces of the device without extra configuration, as the interfaces must be in different autonomous systems and inter-autonomous system redistribute policies do not get pushed down.

The following figure illustrates the route peering object relations:

iBGP Route Peering Object Relations

1. vnsLDevCtx—Device selection policy.

2. l3extOut—Contains all BGP policies for a single autonomous system.

3. bgpCtxPol—Per-context BGP timers.

4. bgpExtP—BGP per ASN policy.

5. l3extLIfP/l3extLNodeP—Controls to which nodes or ports these endpoint groups (EPGs) are deployed.

6. l3extSubnet—Subnets to export from and import into the fabric.

7. l3extInstP—Prefix-based EPG.

The following policy configures iBGPv4/v6 on the external interface:

<polUni>
<fvTenant name="common">
<fvCtx name="commonctx">
<fvRsBgpCtxPol tnBgpCtxPolName="timer-3-9"/>
<fvRsCtxToExtRouteTagPol tnL3extRouteTagPolName="myTagPol"/>
</fvCtx>
<l3extRouteTagPol tag="212" name="myTagPol"/>
<bgpCtxPol grCtrl="helper" holdIntvl="9" kaIntvl="3" name="timer-3-9" staleIntvl="30"/>
<l3extOut name="BgpExternal" status="created,modified">
<l3extLNodeP name="bLeaf-101">
<!-- <bgpPeerP addr="40.40.40.102/32 "ctrl="send-com"/> -->
<l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="180.0.0.8/28>"
<l3extLoopBackIfP addr="50.50.50.100/32"/>
</l3extRsNodeL3OutAtt>
<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/23]"
ifInstT="ext-svi" encap="vlan-3843" addr="40.40.40.100/28 "mtu="1500">
<bgpPeerP addr="40.40.40.102/32 "ctrl="send-com"/>
</l3extRsPathL3OutAtt>
</l3extLIfP>
</l3extLNodeP>
<bgpExtP/>
<l3extInstP name="ExtInstP">
<l3extSubnet ip="40.40.40.100/28 "scope="import-security"/>
<l3extSubnet ip="10.10.10.0/24 "scope="import-security"/>
<l3extSubnet ip="20.20.20.0/24 "scope="export-rtctrl"/>
</l3extInstP>
<l3extRsEctx tnFvCtxName="commonctx"/>
</l3extOut>
</fvTenant>
</polUni>

iBGP peers can be configured at the physical interface level or the loopback level. The following example shows a iBGP peer configured at the physical interface level:

<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/23]"
ifInstT="ext-svi" encap="vlan-3843" addr="40.40.40.100/28 "mtu="1500">
<bgpPeerP addr="40.40.40.102/32 "ctrl="send-com"/>
</l3extRsPathL3OutAtt>
</l3extLIfP>

In this case, the iBGP process that is running on the fabric uses the switch virtual interface (SVI) IP address 40.40.40.100/28 to peer with its neighbor. The neighbor is the service device at IP address 40.40.40.102/32.

In the following example, the iBGP peer definition has been moved to the logical node level (under l3extLNodeP) and a loopback interface has been configured:

<l3extLNodeP name="bLeaf-101">
<bgpPeerP addr="40.40.40.102/32 "ctrl="send-com"/>
<l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="180.0.0.8/28>"
<l3extLoopBackIfP addr="50.50.50.100/32"/>
</l3extRsNodeL3OutAtt>
<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/23]"
ifInstT="ext-svi" encap="vlan-3843" addr="40.40.40.100/28 "mtu="1500">
</l3extRsPathL3OutAtt>
</l3extLIfP>
</l3extLNodeP>

In this case, the iBGP process uses the loopback address to peer with its neighbor. If no loopback is configured, then the fabric uses the IP address that is specified by rtrId to peer with the neighbor.

In such cases, the device needs a route to reach the SVI. This is typically configured using graph parameters, as shown by the following example for ASA, where IP address 50.50.50.0 is reachable from IP address 40.40.40.100:

<vnsAbsFolder name="ExtRouteCfg" key="StaticRoute">
<vnsAbsFolder name="route1" key="route">
<vnsAbsParam name="network" key="network" value="50.50.50.0"/>
<vnsAbsParam name="netmask" key="netmask" value="255.255.255.0"/>
<vnsAbsParam name="gateway" key="gateway" value="40.40.40.100"/>
</vnsAbsFolder>
<vnsAbsFolder name="route2" key="ipv6_route">
<vnsAbsParam name="prefix" key="prefix" value="2005::/64"/>
<vnsAbsParam name="gateway" key="gateway" value="2004::2828:2866"/>
</vnsAbsFolder>
</vnsAbsFolder>

The following example shows static route configuration on the fabric for the internal interface of the device:

<polUni>
<fvTenant name="tenant11">
<l3extOut name="StaticInternal" status="created,modified">
<l3extLNodeP name="bLeaf-201">
<l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="180.0.0.11>"
<ipRouteP ip="20.20.20.0/24>"
<ipNexthopP nhAddr="30.30.30.102/32"/>
</ipRouteP>
</l3extRsNodeL3OutAtt>
<l3extLIfP name="portIf">
<l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/25]"
ifInstT="ext-svi" encap="vlan-3844" addr="30.30.30.100/28 "mtu="1500"/>
</l3extLIfP>
</l3extLNodeP>
<l3extInstP name="IntInstP">
<l3extSubnet ip="20.20.20.0/24 "scope="import-security"/>
</l3extInstP>
<l3extRsEctx tnFvCtxName="tenant1ctx1"/>
</l3extOut>
</fvTenant>
</polUni>

Selecting an L3extOut Policy for a Cluster

A specific l3extOut policy can be associated with a logical device's interface using its selection policy vnsLIfCtx. The following example shows how this is achieved:

<vnsLDevCtx ctrctNameOrLbl="webCtrct1" graphNameOrLbl="WebGraph" nodeNameOrLbl="FW">
<vnsRsLDevCtxToLDev tDn="uni/tn-tenant1/lDevVip-Firewall"/>
<vnsRsLDevCtxToRtrCfg tnVnsRtrCfgName="FwRtrCfg"/>
<vnsLIfCtx connNameOrLbl="internal">
<vnsRsLIfCtxToInstP tDn="uni/tn-tenant1/out-OspfInternal/instP-IntInstP"
status="created,modified"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-tenant1/lDevVip-Firewall/lIf-internal"/>
</vnsLIfCtx>
<vnsLIfCtx connNameOrLbl="external">
<vnsRsLIfCtxToInstP tDn="uni/tn-common/out-OspfExternal/instP-ExtInstP"
status="created,modified"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-tenant1/lDevVip-Firewall/lIf-external"/>
</vnsLIfCtx>
</vnsLDevCtx>

The vnsRsLIfCtxToInstP relation is used to select a particular prefix-based EPG that (l3extInstP) is associated with this leg of the service device. You can specify the redistribute protocol redistribute property on this relation. The default value for the redistribute property is "ospf,bgp". Leaving redistribute at the default value causes the Application Policy Infrastructure Controller (APIC) to auto-detect the routing protocols that are configured on each leg and push the appropriate redistribute settings. The automatic settings always redistribute from an interior gateway protocol (OSPF) to an exterior gateway protocol (BGP).

If you want to use a specific redistribute setting, such as static or connected, then you can add those settings to this relation. For example, redistribute="ospf,bgp,static" causes the auto-detected settings and redistribute-static to be pushed to the service device.

Setting this property to a specific value that does not include the defaults, such as redistribute="ospf,static,connected", causes those exact settings to be pushed to the service device. This is useful in scenarios in which you want to override the defaults that are chosen by the APIC.

Note

The relation points to an EPG (l3extInstP) and not to the l3extOut itself, as there can be multiple such EPGs under an l3extOut policy, and different device selection policies could point to those EPGs. This allows for fine control of which prefixes are imported or exported by different service graphs.

The vnsRsLDevCtxToRtrCfg relation is used to select a particular vnsRtrCfg policy for this device selector. vnsRtrCfg policies are needed to specify the router ID that is used by routing protocols, such as Open Shortest Path First (OSPF) or internal Border Gateway Protocol (iBGP), and must be supplied by the user. This router ID is sent to the device.

The following code is an example vnsRtrCfg policy:

<vnsRtrCfg name="FwRtrCfg" rtrId="180.0.0.10”/>

The associated concrete device must have a vnsRsCIfPathAtt object, which deploys the device to the same fabric leaf as shown below:

<vnsCDev name="ASA">
<vnsCIf name="Gig0/0">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-101/pathep-[eth1/23]"/>
</vnsCIf>
<vnsCIf name="Gig0/1">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-101/pathep-[eth1/25]"/>
</vnsCIf>
<vnsCMgmt name="devMgmt" host="{{asaIp}}" port="443"/>
<vnsCCred name="username" value="admin"/>
<vnsCCredSecret name="password" value="insieme"/>
</vnsCDev>

Note

When route peering is configured, you do not need to configure bridge domains on the vnsLIfCtx selectors. Attempting to configure both bridge domain relations (vnsRsLIfCtxToBD) and l3extInstP relations (vnsRsLIfCtxToInstP) will result in a fault.

Route Peering End-to-End Flow

The following figure shows how route peering works end-to-end.

Route Peering End-to-End Flow

The figure shows an example two leaf, single spine topology where a Linux web server's IP address is advertised to an external router using route peering. The Linux web server is at IP address 10.10.10.101/24 and is hosted on an ESX server that is connected to leaf1. A regular bridge domain-based endpoint group (EPG) is deployed to represent traffic that originates from the web server.

You deploy a service graph that comprises a two-arm routable firewall, with both arms being connected to leaf1. There is a virtual routing and forwarding (VRF)-split on the firewall device, meaning that each arm of the firewall is connected to the leaf in a different VRF (context). The VRF-split is necessary to ensure that traffic is routed through the service device, rather than being short-circuited by the leaf. The external traffic is represented by an l3extOut (L3OutInternet) that is deployed on leaf2. leaf2 can be viewed as a fabric border-leaf in this scenario. You deploy a contract between L3OutInternet and the web server EPG. This contract is associated with a service graph that encompasses the firewall device.

To publish the web server route to the external world, you deploy two l3extOuts—L3OutExternal and L3OutInternal—to the leaf ports to which the service device is connected. As a result, Open Shortest Path First (OSPF) peering sessions are established between the leaf and the firewall in both of the contexts (commonctx and tenant1ctx1). The export attribute on these l3extOuts control how the routing information is advertised to the border leaf. Routes are exchanged internally between the fabric leaves using Multiprotocol Border Gateway Protocol (MP-BGP) redistribution.

Ultimately, the web server route is advertised to the external router (IP address 20.20.20.102) using a separate OSPF session. This results in the external router being able to ping the web server without any manual static route configuration.

Cisco Application Centric Infrastructure Fabric Serving As a Transit Routing Domain

You can deploy the Cisco Application Centric Infrastructure (ACI) fabric as a transit routing domain, which is useful when the ACI point of delivery (POD) serves as a transit routing domain between other PODs. In the following illustration, two external l3extOuts—L3OutInternet and L3OutInternet2—are deployed on two border leaves. There is a contract associated between these l3extOuts, and the contract is attached to a single node service graph containing a firewall service device.

ACI Fabric Serving As a Transit Routing Domain

Two additional l3extOuts are deployed on the external and internal legs of the firewall device to establish Open Shortest Path First (OSPF) peering sessions between them. By appropriately configuring the import security control (the import-security attribute), you can control which routes are allowed to transit the ACI fabric to the border leaves.

Configuring Route Peering Using the GUI

You must perform the following tasks to configure route peering:

1. Create a static VLAN pool that will be used for the encapsulation VLAN between the device and the Cisco Application Centric Infrastructure (ACI) fabric.

See Creating a Static VLAN Pool Using the GUI.

2. Create an external routed domain that will tie together the location (leaf node/path) of the device and the VLAN pool.

See Creating an External Routed Domain Using the GUI.

3. Create an external routed network, which is used to specify the routing configuration in the ACI fabric for route peering.

See Creating an External Routed Network Using the GUI.

4. Create a new router configuration to specify the router ID that will be used on the device.

See Creating a Router Configuration Using the GUI.

5. Create a service graph association, which involves associating the external routed network policy and router configuration with a device selection policy.

See Creating a Service Graph Association Using the GUI.

- Creating a Static VLAN Pool Using the GUI

- Creating an External Routed Domain Using the GUI

- Creating an External Routed Network Using the GUI

- Creating a Router Configuration Using the GUI

- Creating a Service Graph Association Using the GUI

Creating a Static VLAN Pool Using the GUI

Before creating an external routed network configuration, you must create a static VLAN pool that will be used for the encapsulation VLAN between the device and the fabric.

Step 1

On the menu bar, choose Fabric > Access Policies.

Step 2

In the Navigation pane, choose Pools > VLAN.

Step 3

In the Work pane, choose Actions > Create VLAN Pool.

Step 4

In the Create VLAN Pool dialog box, fill in the fields as required, except as specified below:

1. For the Allocation Mode radio buttons, choose Static Allocation.

2. In Encap Blocks section, click +.

Step 5

In the Create Ranges dialog box, enter a unique range of VLANs and click OK.

Step 6

In the Create VLAN Pool dialog box, click Submit.

Creating an External Routed Domain Using the GUI

You must create an external routed domain that ties together the location (leaf node/path) of the device and the static VLAN pool that you created for route peering.

Step 1

On the menu bar, choose FABRIC > Access Policies.

Step 2

In the Navigation pane, right-click Switch Policies and choose Configure Interface, PC, and VPC.

Step 3

In the Configure Interface, PC, and VPC dialog box, to configure switch ports connected to Application Policy Infrastructure Controllers (APICs), perform the following actions:

1. Click the large + icon next to the switch diagram to create a new profile and configure VLANs for the APIC.

2. From the Switches field drop-down list, check the check boxes for the switches to which the APICs are connected.

3. In the Switch Profile Name field, enter a name for the profile.

4. Click the + icon to configure the ports.

5. Verify that in the Interface Type area, the Individual radio button is selected.

6. In the Interfaces field, enter the ports to which APICs are connected.

7. In the Interface Selector Name field, enter the name of the port profile.

8. In the Interface Policy Group field, click the Create One radio button.

9. In the Attached Device Type drop-down list, choose External Routed Devices.

10. For the Domain radio buttons, click the Create One radio button.

11. In the Domain Name field, enter the domain name.

12. If you have previously created a VLAN pool, then for the VLAN radio buttons, click the Choose One radio button. Otherwise, click the Create One radio button.
If you are choosing an existing VLAN pool, in the VLAN Pool drop-down list, choose the VLAN pool.

If you are creating a VLAN pool, in the VLAN Range field, enter the VLAN range.

13. Click Save, and click Save again.

14. Click Submit.

Creating an External Routed Network Using the GUI

The external routed network specifies the routing configuration in the Cisco Application Centric Infrastructure (ACI) fabric for route peering.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose tenant_name > Networking > External Routed Networks.

Step 4

In the Work pane, choose Actions > Create Routed Outside.

Step 5

In the Create Routed Outside dialog box, fill in the fields as required, except as specified below:

1. For dynamic routing, put a check in either the BGP or OSPF check box.
For open shortest path first (OSPF), fill in the additional OSPF-specific fields.

2. In the Private Network drop-down list, choose the private network with which the device will exchange routes.

3. In the External Routed Domain drop-down list, choose the external routed domain that you created for route peering.

4. In the Nodes and Interfaces Protocol Profiles section, click +.

Step 6

In the Create Node Profile dialog box, fill in the fields as required, except as specified below:

1. In the Nodes section, click +.

Step 7

In the Select Node dialog box, fill in the fields as required, except as specified below:

1. In the Node ID drop-down list, choose the node ID where the device is connected.

- For physical devices, the ID should be the node where the physical device is connected to the fabric.

- For virtual devices, the ID should be the node where the server hosting the virtual machine is connected.

2. In the Router ID field, enter a router ID that the ACI fabric will use for the routing protocol process.

3. If you are planning to use static routing between the ACI fabric and device, in the Static Routes section click +. Otherwise, go to step Step 10.

Step 8

In the Create Static Route dialog box, fill in the fields as required, except as specified below:

1. In the Prefix section, enter a prefix for the static route.

2. In the Next Hop Addresses section, click +.

3. Enter the next hop IP address for the static route.

4. Click Update.

Step 9

Click OK.

Step 10

In the Select Node dialog box, click OK.

Step 11

If you are using BGP as the dynamic routing protocol with the device, in the BGP Peer Connectivity Profiles section, click +. Otherwise, go to step Step 14.

Step 12

In the Create Peer Connectivity Profile dialog box, fill in the fields as required, except as specified below:

1. In the Peer Address field, enter a peer address, which should be an IP address on the device with which the BGP session will be established.

Step 13

In the Create Peer Connectivity Profile dialog box, click OK.

Step 14

In the Interface Profiles section, click +.

Step 15

In the Create Interface Profile dialog box, fill in the fields as required.

1. If you are using OSPF as the dynamic routing protocol, enter the OSPF profile information.

Step 16

In the Interface section, choose the SVI tab.

Step 17

In the Interface section, click +.

Step 18

In the Select SVI Interface dialog box, fill in the fields as required, except as specified below:

1. For the Path Type radio buttons, choose the type that matches how the device is connected to the fabric.

2. In the Path drop-down list, choose the path where the device is connected to the fabric.

- For physical devices, this is the path where the physical device is connected to the fabric.

- For virtual devices, this is the path where the server that is hosting the virtual machine is connected.

3. In the Encap field, specify the encapsulation VLAN.

4. In the IP Address field, specify the IP address to use on the fabric SVI interface.

5. In the MTU (bytes) field, specify the maximum transmission unit size, in bytes.
The default value is "inherit", which uses a default value of "9000" on the ACI and typically a default value of "1500" on the remote device. Having different MTU values can cause issues when peering between the ACI and the remote device. If the remote device's MTU value is set to "1500", then set the MTU value on the remote device's L3Out object to "9000" to match the ACI's MTU value.

Step 19

Click OK.

Step 20

In the Create Interface Profile dialog box, click OK.

Step 21

In the Create Node Profile dialog box, click OK.

Step 22

In the Create Routed Outside dialog box, click Next.

Step 23

In the External EPG Networks section, click +.

Step 24

In the Create External Network dialog box, fill in the fields as required, except as specified below:

1. In the Subnet section, click +.

Step 25

In the Create Subnet dialog box, fill in the fields as required, except as specified below:

1. In the IP Address field, enter the IP address or subnet mask.
The subnet mask is equivalent to a network statement that is defined in a traditional routing protocol configuration.

Step 26

Click OK.

Step 27

(Optional) Create additional subnets as needed.

Step 28

In the Create External Network dialog box, click OK.

Step 29

In the Create Routed Outside dialog box, click Finish.

Creating a Router Configuration Using the GUI

As part of the routing protocol configuration, you must specify the router ID that will be used on the device.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose tenant_name > Networking > External Routed Networks > Router Configuration.

Step 4

In the Work pane, in the Router Configurations table, click +.

Step 5

Enter an IP address to use as the router ID on the device.

Step 6

Click Update.

Creating a Service Graph Association Using the GUI

You must create a service graph association, which involves associating the external routed network policy and router configuration with a device selection policy.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose tenant_name > L4-L7 Services > Device Selection Policies > device_selection_policy. device_selection_policy is the device selection policy with which you want to perform route peering with the Cisco Application Centric Infrastructure (ACI) fabric.

Step 4

In the Work pane, in the properties section, in the Router Config drop-down list, choose the router configuration that you created for route peering.

Step 5

In the Navigation pane, expand the chosen device selection policy and choose the interface that will peer with the ACI fabric.

Step 6

In the Work pane, in the properties section, for the Associated Network radio buttons, choose L3 External Network.

Step 7

In the L3 External Network drop-down list, choose the external routed network that you created for route peering.

The following changes occur:

- The encapsulation VLAN for the interface that is associated with the external routed network is reprogrammed to match the VLAN that is configured as part of the external routed network interface profile

- The external routed network interface and routing protocol configuration is pushed to the leaf switch

- The routing protocol configuration is pushed to the device using the device package

Configuring Route Peering Using the NX-OS-Style CLI

This section provides example commands of using the NX-OS-style CLI to configure route peering.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

Example:

apic1(config)# tenant 101

Step 3

Add a service graph and associate it with a contract.

Example:

apic1(config-tenant)# l4l7 graph g1 contract c1

Step 4

Add a node (service) that is associated with the device cluster.

Example:

apic1(config-graph)# service ASA_FW device-cluster-tenant 101 device-cluster ASA_FW1

Step 5

Under the service function, configure the consumer connector and provider cluster-interface.

Example:

apic1(config-service)# connector consumer cluster-interface provider

Step 6

Under the cluster-interface, specify the Layer 3 outside (l3extOut) and the endpoint group (l3extInstP) to be used for route peering with the service device, then exit the connector configuration mode.

Example:

apic1(config-connector)# l4l7-peer tenant 101 out l101 epg e101 redistribute bgp
apic1(config-connector)# exit

Step 7

Repeat step 5 and step 6 for the provider connector and consumer cluster-interface.

Example:

apic1(config-service)# connector provider cluster-interface consumer
apic1(config-connector)# l4l7-peer tenant 101 out l101 epg e101 redistribute bgp
apic1(config-connector)# exit

Step 8

(Optional) If you want to disassociate the endpoint group from the connector, use the no l4l7-peer command.

Example:

apic1(config-connector)# no l4l7-peer tenant 101 out l101 epg e101 redistribute bgp

Step 9

Create a router configuration policy under a tenant, supply a router ID for the peer Layer 4 to Layer 7 device, and exit back to the configuration mode.

Example:

apic1(config)# tenant 102
apic1(config-tenant)# rtr-cfg bgp1
apic1(config-router)# router-id 1.2.3.5
apic1(config-router)# exit

Step 10

Associate the router configuration policy with a particular service device and exit back to the tenant configuration mode.

Example:

apic1(config-tenant)# l4l7 graph g2 contract c2 subject http
apic1(config-graph)# service ASA_FW device-cluster-tenant 102 device-cluster ASA_FW2
apic1(config-service)# rtr-cfg bgp1
apic1(config-service)# exit
apic1(config-graph)# exit

Step 11

Associate a Layer 3 outside with a leaf interface and a VRF:

Example:

apic1(config-tenant)# external-l3 epg e101 l3out l101
apic1(config-tenant-l3ext-epg)# vrf member v101
apic1(config-tenant-l3ext-epg)# match ip 101.101.1.0/24
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant 101 vrf v101 l3out l101
apic1(config-leaf-vrf)# ip route 101.101.1.0/24 99.1.1.2
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# interface ethernet 1/10
apic1(config-leaf-if)# vrf member tenant 101 vrf v101 l3out l101
apic1(config-leaf-if)# vlan-domain member dom101
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# ip address 99.1.1.1/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit

For the complete configuration for Layer 3 external connectivity (Layer 3 outside) using the named mode, including routing protocols (BGP, OSPF) and route maps, see the Cisco APIC NX-OS Style CLI Command Reference document.

Note

The external Layer 3 configuration in the CLI is available in two modes: basic mode and named mode. For a given tenant or VRF, user only one of these modes for all external Layer 3 configuration. Route peering is supported only in the named mode.

Troubleshooting Route Peering

If your Cisco Application Centric Infrastructure (ACI) fabric has a route peering or data traffic issue, there are several commands that you can run on ACI fabric leaves to troubleshoot the issue.

The following table provides troubleshooting commands that you can run in the switch shell on the fabric leaf.

Command

Description

show ip route vrf all

Displays all of the routes in a particular context, including dynamically learned routes.

show ip ospf neighbor vrf all

Displays Open Shortest Path First (OSPF) peering sessions with neighboring devices.

show ip ospf vrf all

Displays the run-time OSPF configuration in each context.

show ip ospf traffic vrf all

Examines OSPF traffic on each virtual routing and forwarding (VRF) context.

show system internal policymgr stats

Displays the contract filter rules on a particular leaf and examines the packet hit counts on the rules.

The following table provides a troubleshooting command that you can run in the vsh_lc shell.

Command

Description

show system internal aclqos prefix

Examines the IPv4 prefix association rules on a particular leaf and the traffic hit counts on the rules.

In addition to the shell commands, you can check the following things to help with troubleshooting:

- Health count on the device

- All of the faults and NwIssues under a particular tenant

- Verifying the Leaf Switch Route Peering Functionality Using the CLI

Verifying the Leaf Switch Route Peering Functionality Using the CLI

You can use switch shell commands on the fabric leaf to verify the leaf switch configuration and route peering functionality.

Step 1

On the fabric leaf switch where the device is connected, verify that the SVI interface is configured:

fab2-leaf3# show ip interface vrf user1:global
IP Interface Status for VRF "user1:global"
vlan30, Interface status: protocol-up/link-up/admin-up, iod: 134,
IP address: 1.1.1.1, IP subnet: 1.1.1.0/30
IP broadcast address: 255.255.255.255
IP primary address route-preference: 1, tag: 0
lo3, Interface status: protocol-up/link-up/admin-up, iod: 133,
IP address: 10.10.10.1, IP subnet: 10.10.10.1/32
IP broadcast address: 255.255.255.255
IP primary address route-preference: 1, tag: 0

fab2-leaf3#

Interface vlan30 contains the SVI interface configuration and Interface lo3 contains the router ID specified in the external routed network configuration.

Step 2

Verify the Open Shortest Path First (OSPF) configuration on the fabric leaf switch:

fab2-leaf3# show ip ospf vrf user1:global

Routing Process default with ID 10.10.10.1 VRF user1:global
Stateful High Availability enabled
Supports only single TOS(TOS0) routes
Supports opaque LSA
Table-map using route-map exp-ctx-2949120-deny-external-tag
Redistributing External Routes from
static route-map exp-ctx-st-2949120
bgp route-map exp-ctx-proto-2949120
eigrp route-map exp-ctx-proto-2949120
Maximum number of non self-generated LSA allowed 100000
(feature configured but inactive)
Current number of non self-generated LSA 1
Threshold for warning message 75%
Ignore-time 5 minutes, reset-time 10 minutes
Ignore-count allowed 5, current ignore-count 0
Administrative distance 110
Reference Bandwidth is 40000 Mbps
SPF throttling delay time of 200.000 msecs,
SPF throttling hold time of 1000.000 msecs,
SPF throttling maximum wait time of 5000.000 msecs
LSA throttling start time of 0.000 msecs,
LSA throttling hold interval of 5000.000 msecs,
LSA throttling maximum wait time of 5000.000 msecs
Minimum LSA arrival 1000.000 msec
LSA group pacing timer 10 secs
Maximum paths to destination 8
Number of external LSAs 0, checksum sum 0x0
Number of opaque AS LSAs 0, checksum sum 0x0
Number of areas is 1, 1 normal, 0 stub, 0 nssa
Number of active areas is 1, 1 normal, 0 stub, 0 nssa
Area (0.0.0.200)
Area has existed for 00:17:55
Interfaces in this area: 1 Active interfaces: 1
Passive interfaces: 0  Loopback interfaces: 0
SPF calculation has run 4 times
Last SPF ran for 0.000273s
Area ranges are
Area-filter in 'exp-ctx-proto-2949120'
Number of LSAs: 3, checksum sum 0x0
fab2-leaf3#

Step 3

Verify the OSPF neighbor relationship on the fabric leaf switch:

fab2-leaf3# show ip ospf neighbors vrf user1:global
OSPF Process ID default VRF user1:global
Total number of neighbors: 1
Neighbor ID     Pri State            Up Time  Address         Interface
10.10.10.2        1 FULL/BDR         00:03:02 1.1.1.2         Vlan30
fab2-leaf3#

Step 4

Verify that the routes are being learned by the fabric leaf switch:

fab2-leaf3# show ip route vrf user1:global
IP Route Table for VRF "user1:global"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

1.1.1.0/30, ubest/mbest: 1/0, attached, direct
*via 1.1.1.1, vlan30, [1/0], 00:26:50, direct
1.1.1.1/32, ubest/mbest: 1/0, attached
*via 1.1.1.1, vlan30, [1/0], 00:26:50, local, local
2.2.2.0/24, ubest/mbest: 1/0
*via 1.1.1.2, vlan30, [110/20], 00:06:19, ospf-default, type-2
10.10.10.1/32, ubest/mbest: 2/0, attached, direct
*via 10.10.10.1, lo3, [1/0], 00:26:50, local, local
*via 10.10.10.1, lo3, [1/0], 00:26:50, direct
10.122.254.0/24, ubest/mbest: 1/0
*via 1.1.1.2, vlan30, [110/20], 00:06:19, ospf-default, type-2
fab2-leaf3#

Step 5

Verify that OSPF has been configured on the device, which is a Cisco ASAv in this example:

ciscoasa# show running-config
: Saved
:
: Serial Number: 9AGRM5NBEXG
: Hardware:   ASAv, 2048 MB RAM, CPU Xeon 5500 series 2133 MHz
:
ASA Version 9.3(1)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
names
!
interface GigabitEthernet0/0
nameif internalIf
security-level 100
ip address 2.2.2.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif externalIf
security-level 50
ip address 1.1.1.2 255.255.255.252
!
<<..>>
router ospf 1
router-id 10.10.10.2
network 1.1.1.0 255.255.255.252 area 200
area 200
log-adj-changes
redistribute connected
redistribute static
!

Chapter 8. Configuring Direct Server Return

- About Direct Server Return

- Direct Server Return Architecture

- Example XML POST of Direct Server Return for Static Service Deployment

- Direct Server Return for Static Service Deployment

- Direct Server Return for Service Graph Insertion

- Configuring the Citrix Server Load Balancer for Direct Server Return

- Configuring a Linux Server for Direct Server Return

About Direct Server Return

The direct server return feature enables a server to respond directly to clients without having to go through the load balancer, which eliminates a bottleneck in the server-to-client path. In traditional load balancer deployments, the load balancer is in the path of the client-to-server communication: both the client-to-server request path and the server-to-client response path. While the amount of data in the requests from the client-to-server direction are relatively small, the server-to-client response traffic is much higher: approximately 10 times that of client-to-server request data. The load balancer in the path of this high volume response traffic becomes a bottleneck and adversely affects the communication.

For direct server return deployments, a virtual IP address is shared by the load balancer and server. Clients always address their request to the virtual IP address that is intended to reach the load balancer, and the direct response from the server-to-client use this virtual IP address as the source address. Cisco Application Centric Infrastructure (ACI) enabled with data-path learning of the IP source address poses problems when it learns the virtual IP address from the server-to-client traffic, leading to the disruption of Client-to-load balancer request traffic. To allow for the proper operation of a direct server return deployment, the ACI fabric must ensure that the request-response traffic between the communicating endpoints are delivered to their intended destination correctly. This requires that the data-path IP address learning on the leafs must be controlled in such a way that there is no interruption to client-to-load balancer, load balancer-to-server, and server-to-client traffic.

The following figure illustrates the data path in a direct server return deployment:

Direct Server Return High-Level Flow

1. The load balancer and all of the back-end servers are configured with the virtual IP address. The load balancer alone responds to Address Resolution Protocol (ARP) requests for this virtual IP address. After load balancing the client request, the load balancer re-writes the destination MAC address in the packet and forwards the MAC address to one of the back-end servers.

2. The virtual IP address is configured on the back-end server, but ARP is disabled to prevent back-end servers from responding to ARP requests for this virtual IP address.

3. The server sends the return traffic directly to the client, by-passing the load-balancer.

- Layer 2 Direct Server Return

- About Deploying Layer 2 Direct Server Return with Cisco Application Centric Infrastructure

- Supported Direct Server Return Configuration

Layer 2 Direct Server Return

Layer 2 direct server return is the common or traditional deployment, also known as direct routing, SwitchBack, or nPath. In this deployment, the virtual IP address is shared by the load balancer and server. The load balancers and servers must be layer 2 adjacent. A layer 2 direct server return deployment has the following limitations:

- You lose flexibility in server placement

- You need an extra server configuration to suppress Address Resolution Protocol (ARP) responses to client virtual IP address requests

- Port selection is layer 3 and protocol dependent; port selection cannot happen at layer 2 (load balancer to server communication)

A layer 2 direct server return deployment has the following traffic flow:

Layer 2 Direct Server Return Traffic Flow

1. Client to load balancer

Source IP Address

1.1.1.1

Destination IP Address

2.2.2.2

Destination MAC Address

A.A.A

2. Load balancer to server

Source IP Address

1.1.1.1

Destination IP Address

2.2.2.2

Destination MAC Address

B.B.B

3. Server to client

Source IP Address

2.2.2.2

Destination IP Address

1.1.1.1

Destination MAC Address

MAC address of the default gateway

About Deploying Layer 2 Direct Server Return with Cisco Application Centric Infrastructure

The following information applies to deploying layer 2 direct server return with Cisco Application Centric Infrastructure (ACI):

- The virtual IP address (2.2.2.2) moves within the ACI fabric

- The load balancer-to-server and server-to-client traffic with the same source virtual IP address (2.2.2.2)

- The server-to-client traffic is routed; the traffic is addressed to the gateway MAC address in the fabric

- The data-path learning of the source IP address from the server moves to the virtual IP address within the fabric

- There are no issues for the client IP address (1.1.1.1) appearing from difference sources

- The client IP address appears as the source IP address from both the client and the load balancer in the fabric

- The load balancer and server are layer 2 adjacent and the load balancer-to-server traffic is layer 2 forwarded

- There is no data-path IP address learning from layer 2 forwarded traffic in the fabric

- Even if the client IP address appears as the source IP address from the load balancer in the fabric, the client IP address is not learned

Supported Direct Server Return Configuration

The following figure illustrates the supported direct server return configuration:

Supported Direct Server Return Configuration

The following information applies to the supported configuration:

- The server load balancer and servers are in the same subnet and bridge domain

- The server load balancer should operate in 1 ARM mode; the inside and outside legs of server load balancer should point to the same bridge domain

- The consumer and provider endpoint groups should be under the same private network; no shared service configuration is supported

Direct Server Return Architecture

To enable layer 2 direct server return, the virtual IP address that is shared by the load balancer and server can be configured as static within the fabric on the tenant Virtual Routing and Forwarding (VRF). With the virtual IP address being static, the data-path learning of this virtual IP address is prevented. The switch side end-point-manager design handles the static configuration from the policy engine in the form of a {VRF, VIP, S-Class} tuple in the concrete model. While there are no architectural changes to the endpoint manager (EPM), endpoint manager client (EPMC), and forwarding silicon, there are changes in all of these layers to allow and maintain the virtual IP address static configuration. The architecture allows for both virtual IPv4 and virtual IPv6 static configurations. Other than the address parsing and initial setup, architecturally and design-wise, both virtual IPv4 and virtual IPv6 are handled with the same code paths.

The direct server return design flow and configuration flow is part of the EPM/EPMC/USD flow. The flow for this exists only from Northbound-to-Southbound; that is, policy engine > EPM > EPMC > forwarding silicon. The forwarding silicon in this case is North Star, as only the North Star local station table is touched for this purpose. The same endpoint create/modify/delete flow is used with the extra static IP address endpoint flag.

All of the learn requests for any new IP address endpoint goes through a static virtual IP address endpoint check. When the learning/processing request is for the already-existing {VRF, VIP, S-class} tuple, any modification pre-processing is handled by the direct server return pre-processing code and is handled back with the proper flags to generic endpoint processing.

Switch Side Handling

The following list provides a high level view of the direct server return design points:

- All virtual IPv4 and virtual IPv6 add/modify/delete configurations are handled by the endpoint manager

- Direct server return uses full virtual IP addresses (/32, /128), not prefixes

- Code paths are merged for direct server return, other than top level setting up of the address family and address

- The EPM and EPMC install the full (32 or /128) virtual IP address in the North Star local station table source address

- The key/data comes from the configured 3-tuple {VRF, VIP, S-class} information

- The entry is populated in the local station table source address as "Static"

- The EPM allows for the discovery of a load balancer endpoint through ARP/GARP/ND IP-MAC binding and MAC learning

- The EPM and EPMC prevent spurious North Star data-path learning of the {VRF, VIP} tuple.

- The EPM and EPMC disallow IP-MAC binding association when the learned entry S-class mismatches with the {VRF, VIP, S-class} tuple that is configured in the policy engine; this is applicable to both the ARP/GARP/ND path and the data-path learning path

- The EPM does not alter the discovery dissemination of a load balancer (through ARP/GARP/ND) to COOP

- During configuration, the EPM and EPMC clean up the existing learned entry (ARP/GARP/ND) when the entry's S-class does not match

- When configuring the virtual IP address, the EPM and EPMC always clean up the existing entry for the same {VRF, VIP} tuple that was created through data-path learning

- ARP/ND/MAC aging is not touched by these changes, but the EPM and EPMC ensure that unless there is a configuration delete for the {VRF, VIP} tuple, the static entry maintained in the local station table is never deleted

- The implementation of this feature takes the approach of keeping the {VRF, VIP} tuple entry learned through ARP/GARP/ND when the same entry configuration comes from policy engine, rather than deleting the existing entry; this is only when the existing entry's S-class is same as the configured entry S-class. This approach is taken to avoid the fabric wide churn that would otherwise happen due to the deletion of the entry

- The S-class and other information related to the entry is kept as part of the IP address information; that is, the information is kept at the endpoint's IP address level, not at the endpoint level

- When there is a overlap between the {BD, Prefix of virtual IP, S-class} tuple and the policy engine-configured {VRF, VIP, S-class} tuple, precedence is given to the {VRF, virtual IP, S-class} tuple

Example XML POST of Direct Server Return for Static Service Deployment

The following XML POST is an example of direct server return static service deployment:

<fvAp name="dev">
<fvAEPg name="loadbalancer">
<fvRsDomAtt tDn="uni/phys-{{tenantName}}"/>
<fvRsBd tnFvBDName="lab"/>
<fvVip addr="121.0.0.{{net}}" />
<fvRsPathAtt tDn="topology/pod-1/paths-104/pathep-[eth1/1]" encap="vlan-33" />
<fvRsProv tnVzBrCPName="loadBalancer"/>
<fvRsCons tnVzBrCPName="webServer"/>
</fvAEPg>
<fvAEPg name="webServer">
<fvRsDomAtt tDn="uni/phys-{{tenantName}}"/>
<fvRsBd tnFvBDName="lab"/>
<fvRsPathAtt tDn="topology/pod-1/paths-101/pathep-[eth1/1]" encap="vlan-34"/>
<fvRsProv tnVzBrCPName="webServer"/>
</fvAEPg>
<fvAEPg name="client">
<fvRsDomAtt tDn="uni/phys-{{tenantName}}"/>
<fvRsBd tnFvBDName="lab"/>
<fvRsPathAtt tDn="topology/pod-1/paths-103/pathep-[eth1/4]" encap="vlan-1114"/>
<fvRsCons tnVzBrCPName="loadBalancer"/>
</fvAEPg>
</fvAp>

The direct server return configuration is downloaded to all of the top-of-rack switches (ToR) where the toEPG contract exists for the Web server. In the example, the direct server return virtual IP address configuration will be downloaded to the ToR denoted "paths-101". You should not see a static configuration of the virtual IP address downloaded on ToR that is denoted by node-ID 104.

The direct server return configuration can be issued without the existence of the toEPG contract. Whenever the contract is created, the direct server return virtual IP address, if already configured, will be automatically downloaded to the ToR where the Web server toEPG contract exists.

Direct Server Return for Static Service Deployment

In the static service deployment mode, you configure the service flow by creating the appropriate application endpoint groups and contracts on a hop-by-hop basis.

- Direct Server Return for Static Service Deployment Logical Model

Direct Server Return for Static Service Deployment Logical Model

You can configure the virtual IP addresses that are used by the load balancers by using the fvVip object under an application endpoint group (fvAEPg).

The following figure illustrates the logical model for static service deployment:

Static Service Deployment Logical Model

Direct Server Return for Service Graph Insertion

The Cisco Application Centric Infrastructure (ACI) provides automated service insertion by using vendor packages and service graphs. In this mode, the endpoint groups that are created for the service device legs, such as inside and outside endpoint groups, are created by the ACI without the operator configuration.

For service graph insertion, you must configure the virtual IP addresses under the appropriate logical interface context for the service device, as shown in the following example XML POST:

<vnsLDevCtx ctrctNameOrLbl="webCtrct"
graphNameOrLbl="G1"
nodeNameOrLbl="SLB">

<vnsRsLDevCtxToLDev tDn="uni/tn-coke/lDevVip-InsiemeCluster"/>

<vnsLIfCtx connNameOrLbl="inside">
<vnsRsLIfCtxToBD tDn="uni/tn-coke/BD-cokeBD1"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-coke/lDevVip-InsiemeCluster/lIf-inside"/>
</vnsLIfCtx>

<vnsLIfCtx connNameOrLbl="outside">
<vnsRsLIfCtxToBD tDn="uni/tn-coke/BD-cokeBD1"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-coke/lDevVip-InsiemeCluster/lIf-outside"/>
<vnsSvcVip addr="9.9.9.9" />
<vnsSvcVip addr="11.11.11.11" />
</vnsLIfCtx>
</vnsLDevCtx>

The sample request configures two virtual IP addresses (9.9.9.9 and 11.11.11.11) on the outside leg of the server load balancer. The virtual IP address definition is under LIfCtx instead of being under an endpoint group as it is with a static direct server return configuration. This is because in the service graph case, operators do not have direct access to an endpoint group for the device legs, unlike with a static service deployment.

- Direct Server Return Shared Layer 4 to Layer 7 Service Configuration

Direct Server Return Shared Layer 4 to Layer 7 Service Configuration

When the service device is configured in the common tenant or management tenant, the implicit model differs slightly. Instead of vnsEPpInfo, the service virtual IP address update managed object is created as a child of vnsREPpInfo. One vnsSvcEpgCont managed object is created per vnsRsEPpInfo to keep track of shared SvcVips across tenants.

Configuring the Citrix Server Load Balancer for Direct Server Return

The following procedure provides an overview of how to configure the Citrix server load balancer for direct server return.

Step 1

Configure the virtual IP address on the backend server's loopback so that the backend server accepts the packets.

Step 2

Disable Address Resolution Protocol (ARP) reply for the virtual IP address on backend server.

Step 3

If necessary, disable the proxy port on services that are bound to the load balancing virtual server. The proxy port is disabled by default.

Step 4

Set the m parameter to "MAC" on the load balancing virtual server.

Step 5

Enable the USIP mode either globally or for each service.

Step 6

Enable the "L3", "USNIP", and "MBF" modes.

Step 7

Configure a route on the backend servers so that they can reach the Internet directly.

Configuring a Linux Server for Direct Server Return

The following procedure provides an overview of how to configure a Linux server for direct server return.

Step 1

Configure the virtual IP addresses on the loopback interfaces by creating the /etc/sysconfig/network-scripts/ifcfg-lo file in Centos with the following contents:

DEVICE=lo:1
IPADDRESS=10.10.10.99
NETMASK=255.255.255.255
NETWORK=10.10.10.99
BROADCAST=10.10.10.99
ONBOOT=yes
NAME=loopback

In this example, 10.10.10.99 is the virtual IP address.

Step 2

Set the arp_ignore and arp_announce settings in the server interface that is used to reply to client request:

echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth1/arp_announce

In this example, eth1 is the server interface used to respond to client requests.

For more information about the ARP settings, see the following Linux Virtual Server wiki page:

Click Here

Chapter 9. Configuring the Device and Chassis Manager

- About Device Managers and Chassis Managers

- Device Manager and Chassis Manager Behavior

- Creating a Device Manager Using the GUI

- Creating a Chassis Using the GUI

- Example XML for Device Managers and Chassis Managers

- Device and Chassis Callouts

About Device Managers and Chassis Managers

A device manager serves as a single point of configuration for a set of clusters in a Cisco Application Centric Infrastructure (ACI) fabric. The administration or operational state is presented in the native GUI of the devices. A device manager handles configuration on individual devices and enables you to simplify the configuration in the Application Policy Infrastructure Controller (APIC). You create a template in device manager, then populate the device manager with instance-specific values from the APIC, which requires only a few values.

The following figure illustrates a device manager controlling multiple devices in a cluster:

Controlling Devices with a Device Manager

A chassis manager is a physical or virtual "container" of processing resources. A chassis manager supports a number of virtual service devices that are represented as CDev objects. A chassis manager handles networking, while CDev handles processing. A chassis manager enables the on-demand creation of virtual processing nodes. For a virtual device, some parts of a service (specifically the VLANs) must be applied to the chassis rather than to the virtual machine. To accomplish this, the chassis management IP address and credentials must be included in callouts.

The following figure illustrates a chassis manager acting as a container of processing resources:

Controlling Devices with a Device Manager

Without a device manager or chassis manager, the model for service devices contains the following key managed objects:

- MDev—Represents a device type (vendor, model, version).

- LDevVIP—Represents a cluster, a set of identically configured devices for high availability (HA). Contains CMgmt and CCred for access to the device.

- CDev—Represents a member of a cluster, either physical or virtual. Contains CMgmt and CCred for access to the device.

- VDev—Represents a context on a cluster, similar to a virtual machine on a server.

The following figure illustrates the model for the key managed objects, with CMgmt (management connectivity) and CCred (credentials) included:

Managed Object Model Without a Device Manager or Chassis Manager

CMgmt (host + port) and CCred (username + password) allow the script to access the device and cluster.

A device manager and chassis manager adds the ability to control the configuration of clusters and devices from a central management station. The chassis adds a parallel hierarchy to the MDev object and ALDev object to allow a CDev object to be tagged as belonging to a specific chassis. The following managed objects are added to the model to support the device and chassis manager concept:

- MDevMgr—Represents a type of device manager. An MDevMgr can manage a set of different MDevs, which are typically different products from the same vendor.

- DevMgr—Represents a device manager. Access to the manager is provided using the contained CMgmt and CCred managed objects. Each cluster can be associated with only one DevMgr.

- MChassis—Represents a type of chassis. This managed object is typically included in the package.

- Chassis—Represents a chassis instance. It contains the CMgmt and CCred[Secret] managed objects to provide connectivity to the chassis.

The following figure illustrates the device manager object model:

Device Manager Object Model

The following figure illustrates the chassis manager object model:

Chassis Manager Object Model

Device Manager and Chassis Manager Behavior

The following behavior applies regarding device managers and chassis managers:

- The DevMgr object is not required. If there is no relation from LDevVip to DevMgr, then the system performs callouts without the device manager being defined.

- Policymgr performs a sanity check to ensure that the relation from LDevVip to MDev matches one relation path from LDevVip through DevMgr and MDevMgr to MDev. A fault is raised if this is not the case, which prevents further callouts.

- If a relation from LDevVip to DevMgr, from DevMgr to MDevMgr, or from MDevMgr to the correct MDev is added or changed, then the cluster is reset and configured from scratch

- The Chassis object is not required. If there is no relation from CDev to Chassis, then the system performs callouts without the chassis being defined.

- Policymgr performs a sanity check to ensure that the relation from CDev through LDevVip to MDev matches one relation path from CDev through Chassis and MChassis to MDev. A fault is raised if this is not the case, which prevents further callouts.

- If a relation from CDev to Chassis, from Chassis to MChassis, or from MChassis to the correct MDev is added or changed, then the cluster is reset and configured from scratch

Creating a Device Manager Using the GUI

You can create a device manager for a tenant using the GUI.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click a tenant's name.

Step 3

In the Navigation pane, choose tenant_name > L4-L7 Services > Device Managers.

Step 4

In the Work pane, choose Actions > Create Device Manager.

Step 5

In the Create Device Manager dialog box, fill in the fields as required.

Step 6

Click Submit.

Creating a Chassis Using the GUI

You can create a chassis for a tenant using the GUI.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click a tenant's name.

Step 3

In the Navigation pane, choose tenant_name > L4-L7 Services > Chassis.

Step 4

In the Work pane, choose Actions > Create Chassis.

Step 5

In the Create Chassis dialog box, fill in the fields as required.

Step 6

Click Submit.

Example XML for Device Managers and Chassis Managers

The example XML in the following sections assumes that the Insieme package has been loaded, which provides the uni/infra/mDev-Insieme-Generic-1.0 distinguished name.

- Example XML for Creating the MDevMgr Object

- Example XML for Associating an LDevVip Object With a DevMgr Object

- Example XML for Creating the MChassis Object

- Example XML for Creating the Chassis Object

- Example XML for Associating an CDev Object With a Chassis Object

Example XML for Creating the MDevMgr Object

The MDevMgr object is analogous with the MDev object and has vendor, model, and version as the naming properties. Multiple MDevMgrToMDev relations can be created if the manager can manage different types of clusters. The following example XML creates the MDevMgr object:

<polUni>
<infraInfra>
<vnsMDevMgr
vendor="Insieme"
model="DevMgr"
version="1.0"
>
<vnsRsMDevMgrToMDev tDn="uni/infra/mDev-Insieme-Generic-1.0"/>
</vnsMDevMgr>
</infraInfra>
</polUni>

The following example XML creates the MDevMgr object within the tenant1 tenant:

<polUni>
<fvTenant name="tenant1">
<vnsDevMgr name="Foo">
<vnsCMgmts
host="10.10.11.11"
port="1234"/>
<vnsCMgmts
host="10.10.11.12"
port="1234"/>
<vnsCMgmts
host="10.10.11.13"
port="1234"/>
<vnsCCred name="username" value="admin"/>
<vnsCCredSecret name="password" value="letmein"/>
<vnsRsDevMgrToMDevMgr tDn="uni/infra/mDevMgr-Insieme-DevMgr-1.0"/>
</vnsDevMgr>
</fvTenant>
</polUni>

Example XML for Associating an LDevVip Object With a DevMgr Object

Association of the LDevVip object with the DevMgr object is done by creating a relation from LDevVip to DevMgr, as shown in the following example XML:

<polUni>
<fvTenant name="tenant1">
<vnsLDevVip name="InsiemeCluster" devtype="VIRTUAL">
...
<vnsRsMDevAtt tDn="uni/infra/mDev-Insieme-Generic-1.0"/>
<vnsRsALDevToDevMgr tDn="uni/tn-tenant1/devMgr-Foo"/>
...
</vnsLDevVip>
</fvTenant>
</polUni>

Example XML for Creating the MChassis Object

The MChassis object is analogous with the MDev object and has vendor, model, and version as the naming properties. A MChassisToMDev relation determines the device type. The following example XML creates the MChassis object:

<polUni>
<infraInfra>
<vnsMChassis vendor="Insieme" model="DevMgr" version="1.0">
<vnsRsMChassisToMDev tDn="uni/infra/mDev-Insieme-Generic-1.0"/>
</vnsMChassis>
</infraInfra>
</polUni>

Example XML for Creating the Chassis Object

The following example XML creates the Chassis object:

<polUni>
<fvTenant name="tenant1">
<vnsChassis name="Foo">
<vnsCMgmts
host="10.10.11.11"
port="1234"/>
<vnsCMgmts
host="10.10.11.12"
port="1234"/>
<vnsCMgmts
host="10.10.11.13"
port="1234"/>
<vnsCCred name="username" value="admin"/>
<vnsCCredSecret name="password" value="letmein"/>
<vnsRsChassisToMChassis tDn="uni/infra/mChassis-Insieme-DevMgr-1.0"/>
</vnsChassis>
</fvTenant>
</polUni>

Example XML for Associating an CDev Object With a Chassis Object

Association of the CDev object with the Chassis object is done by creating a relation from CDev to Chassis, as shown in the following example XML:

<polUni>
<fvTenant name="tenant1">
<vnsLDevVip name="InsiemeCluster" devtype="VIRTUAL">
...
<vnsCDev name="Generic1" devCtxLbl="C1">
...
<vnsRsCDevToChassis tnVnsChassisName="Foo"/>
</vnsCDev>
<vnsRsALDevToDevMgr tDn="uni/tn-coke/devMgr-Foo"/>
...
</vnsLDevVip>
</fvTenant>
</polUni>

Device and Chassis Callouts

The following sections contain device, cluster, and service callout examples that include parameters for the device and chassis manager. The parameters are added to all callouts.

- Example deviceValidate Callout for a Device

- Example deviceAudit Callout for a Device

- Example clusterAudit Callout for a Device

- Example serviceAudit Callout for a Device

- Example deviceValidate Callout for a Chassis

- Example deviceAudit Callout for a Chassis

- Example clusterAudit Callout for a Chassis

- Example serviceAudit Callout for a Chassis

Example deviceValidate Callout for a Device

In the following example deviceValidate callout, the device-specific code is shown in bold:

2014-10-03 17:38:51,035 DEBUG 140230105585408 [42.42.42.101, 0]:  deviceValidate
{'args': ('1.0',),
'device': {'creds': {'password': '<hidden>', 'username': 'nsroot'},
'host': '42.42.42.101',
'manager': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Example deviceAudit Callout for a Device

In the following example deviceAudit callout, the device-specific code is shown in bold:

2014-10-03 17:38:56,072 DEBUG 140230088800000 [42.42.42.100, 2]:  deviceAudit
{'args': ({(11, '', 'ext'): {'label': 'in', 'state': 0},
(11, '', 'int'): {'label': 'out', 'state': 0}},
{(4, 'oneFolder', 'foo'): {'ackedState': 0,
'state': 0,
'transaction': 0,
'value': {(5, 'oneParam', 'foo'): {'ackedState': 0,
'state': 0,
'transaction': 0,
'value': 'bar'}}}}),
'device': {'creds': {'password': '<hidden>', 'username': 'nsroot'},
'host': '42.42.42.100',
'manager': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Example clusterAudit Callout for a Device

In the following example clusterAudit callout, the device-specific code is shown in bold:

2014-10-03 17:39:01,097 DEBUG 140229734295296 [42.42.42.99, 4]:  clusterAudit
{'args': ({(12, '', 'ext'): {'cifs': {'Generic1': 'ext', 'Generic2': 'ext'},
'label': 'in',
'state': 0},
(12, '', 'inside'): {'cifs': {'Generic1': 'ext',
'Generic2': 'ext'},
'label': 'in',
'state': 0},
(12, '', 'int'): {'cifs': {'Generic1': 'int', 'Generic2': 'int'},
'label': 'out',
'state': 0},
(12, '', 'outside'): {'cifs': {'Generic1': 'int',
'Generic2': 'int'},
'label': 'out',
'state': 0}},
{}),
'device': {'creds': {'password': '<hidden>', 'username': 'nsroot'},
'devs': {'Generic1': {'creds': {'password': '<hidden>',
'username': 'nsroot'},
'host': '42.42.42.100',
'port': 80,
'virtual': True},
'Generic2': {'creds': {'password': '<hidden>',
'username': 'nsroot'},
'host': '42.42.42.101',
'port': 80,
'virtual': True}},
'host': '42.42.42.99',
'manager': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.10.11': {'port': 1234},
'10.10.10.12': {'port': 1234},
'10.10.10.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Example serviceAudit Callout for a Device

In the following example serviceAudit callout, the device-specific code is shown in bold:

2014-10-03 17:39:06,169 DEBUG 140229725902592 [42.42.42.99, 5]:  serviceAudit
{'args': ({(0, '', 4474): {'ackedState': 0,
'state': 2,
'transaction': 0,
'txid': 10000,
'value': {(1, '', 5787): {
...
}},
'device': {'creds': {'password': '<hidden>', 'username': 'nsroot'},
'devs': {'Generic1': {'creds': {'password': '<hidden>',
'username': 'nsroot'},
'host': '42.42.42.100',
'port': 80,
'virtual': True},
'Generic2': {'creds': {'password': '<hidden>',
'username': 'nsroot'},
'host': '42.42.42.101',
'port': 80,
'virtual': True}},
'host': '42.42.42.99',
'manager': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Example deviceValidate Callout for a Chassis

In the following example deviceValidate callout, the chassis-specific code is shown in bold:

2014-11-13 19:33:16,066 DEBUG 140719921972992 [42.42.42.101, 0]: request: deviceValidate
{'args': ('1.0',),
'device': {'chassis': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'creds': {'username': 'nsroot', 'pasword': '<hidden>'},
'host': '42.42.42.100',
'port': 80,
'virtual': True}}

Example deviceAudit Callout for a Chassis

In the following example deviceAudit callout, the chassis-specific code is shown in bold:

2014-10-03 17:38:56,072 DEBUG 140230088800000 [42.42.42.100, 2]:  deviceAudit
{'args': ({(11, '', 'ext'): {'label': 'in', 'state': 0},
(11, '', 'int'): {'label': 'out', 'state': 0}},
{(4, 'oneFolder', 'one'): {'ackedState': 0,
'state': 0,
'transaction': 0,
'value': {(5, 'oneParam', 'one'): {'ackedState': 0,
'state': 0,
'transaction': 0,
'value': 'foo'}}}}),
'device': {'chassis': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'creds': {'password': '<hidden>', 'username': 'nsroot'},
'host': '42.42.42.101',
'manager': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.10.11': {'port': 1234},
'10.10.10.12': {'port': 1234},
'10.10.10.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Example clusterAudit Callout for a Chassis

In the following example clusterAudit callout, the chassis-specific code is shown in bold:

2014-10-03 17:39:01,097 DEBUG 140229734295296 [42.42.42.99, 4]:  clusterAudit
{'args': ({(12, '', 'ext'): {'cifs': {'Generic1': 'ext', 'Generic2': 'ext'},
'label': 'in',
'state': 0},
(12, '', 'inside'): {'cifs': {'Generic1': 'ext',
'Generic2': 'ext'},
'label': 'in',
'state': 0},
(12, '', 'int'): {'cifs': {'Generic1': 'int', 'Generic2': 'int'},
'label': 'out',
'state': 0},
(12, '', 'outside'): {'cifs': {'Generic1': 'int',
'Generic2': 'int'},
'label': 'out',
'state': 0}},
{}),
'device': {'creds': {'password': '<hidden>', 'username': 'nsroot'},
'devs': {'Generic1': {'chassis': {'creds': {'password': '<hidden>',
'username': 'admin'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'creds': {'username': 'nsroot', 'pasword': '<hidden>'},
'host': '42.42.42.100',
'port': 80,
'virtual': True},
'Generic2': {'chassis': {'creds': {'password': '<hidden>',
'username': 'admin'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'creds': {'username': 'nsroot', 'pasword': '<hidden>'},
'host': '42.42.42.101',
'port': 80,
'virtual': True}},
'host': '42.42.42.99',
'manager': {'creds': {'password': '<hidden>', 'username': 'admin'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Example serviceAudit Callout for a Chassis

In the following example serviceAudit callout, the chassis-specific code is shown in bold:

2014-10-03 17:39:06,169 DEBUG 140229725902592 [42.42.42.99, 5]:  serviceAudit
{'args': ...,
'device': {'creds': {'password': '<hidden>', 'username': 'nsroot'},
'devs': {'Generic1': {'chassis': {'creds': {'username': 'admin',
'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'creds': {'username': 'nsroot',
'pasword': '<hidden>'},
'host': '42.42.42.100',
'port': 80,
'virtual': True},
'Generic2': {'chassis': {'creds': {'username': 'admin',
'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'creds': {'username': 'nsroot',
'pasword': '<hidden>'},
'host': '42.42.42.101',
'port': 80,
'virtual': True}},
'host': '42.42.42.99',
'manager': {'creds': {'username': 'admin', 'password': '<hidden>'},
'hosts': {'10.10.11.11': {'port': 1234},
'10.10.11.12': {'port': 1234},
'10.10.11.13': {'port': 1234}},
'name': 'Foo'},
'port': 80,
'version': '1.0',
'virtual': True}}

Chapter 10. Configuring Unmanaged Mode

- About the Unmanaged Mode

- About Managed and Unmanaged Logical Devices

- About Managed and Unmanaged Function Nodes

- About Layer 4 to Layer 7 Services Endpoint Groups

- Using Static Encapsulation for a Graph Connector

- Creating a Physical Device Using the NX-OS-Style CLI

- Creating a High Availablity Cluster Using the NX-OS-Style CLI

- Creating a Virtual Device Using the NX-OS-Style CLI

- Example XML for the Unmanaged Mode

- Unmanaged Mode Behavior

About the Unmanaged Mode

The Layer 4 to Layer 7 service insertion feature enables an administrator to insert one or more services between two endpoint groups. The Application Policy Infrastructure Controller (APIC) allocates the fabric resources (VLANs) for the services and programs fabric (leafs) and service appliances as per the configuration specified in the service graph. The APIC requires the device package for a service to be able to use it as part of the service graph. The APIC also programs the service appliance during graph instantiation.

You might want the APIC to allocate only the network resources for the service graph and program only the fabric side during graph instantiation. This might be needed for various reasons, such as if your environment already has an existing orchestrator or a dev-op tool that is more suitable for programming the service appliance. In some other cases, the device package for the service appliance is not available.

The unmanaged mode for services enables you to choose the APIC's behavior for allocating network resources and programming the fabric. When enabled, the unmanaged mode restricts the APIC to allocate only the network resources for a service appliance and to program only the fabric (leaf). The configuration of the device is left to be done externally by you.

About Managed and Unmanaged Logical Devices

The unmanaged mode introduces the managed setting to the logical device (LDevVip), as shown in the following XML code:

<!-- Specified if the device is a managed device-->
<property name="managed"
type="scalar:Bool"
owner="management"
mod="explicit">
<default value="true"/>
</property>

A device can be either managed or unmanaged. When a device is configured as managed, the Application Policy Infrastructure Controller (APIC) manages the device and programs the device during graph instantiation. By default, when a device is registered with the APIC, the device is set to be in managed mode.

If a device is configured as unmanaged, meaning that the managed setting is set to false, the APIC does not program the device. The APIC only allocates the network resources and programs the VLAN/VXLAN on the fabric side.

The following settings are not needed when a device cluster is configured as unmanaged:

- Device package

- Connectivity information for the logical device (vnsLDevViP) and devices (CDev)—management IP address, credentials, and in-band connectivity information

- Information about supported function type (go-through, go-to)

- Information about context awareness (single context or multi-context)

The APIC still needs to know the topology information (LIF, CIF) for the logical device and devices. This information is needed so that the APIC can program the appropriate ports on the leaf and the APIC can also use this information for troubleshooting wizard purposes.

The APIC also needs to know the relation to DomP, which is used for allocating the encapsulation.

About Managed and Unmanaged Function Nodes

The unmanaged mode introduces the managed setting to the function node (AbsNode), as shown in the following XML code:

<!-- Specified if the function is using a managed device-->
<property name="managed"
type="scalar:Bool"
owner="management"
mod="explicit">
<default value="true"/>
</property>

A function node can be either managed or unmanaged. When a function node is configured as managed, the function node can use a managed device. The Application Policy Infrastructure Controller (APIC) programs the device during graph instantiation. By default, when a function node is added to the service graph, the function node is set to be in managed mode.

If a function node is configured as unmanaged, meaning that the managed setting is set to false, the APIC does not do parameter resolution nor program the devices. The APIC only allocates the network resources and programs the VLAN/VXLAN on fabric side.

The following settings are not needed when a function node is configured as unmanaged:

- MFunc relation

- AbsFuncProfile

- Configuration parameters (in AbsNode or on an endpoint group)

- Information about the supported function type (go-through, go-to)

The APIC still needs to know the network information (LIF, CIF) for the function node. This information is needed so that the APIC can program the network appropriately on the leaf, and the APIC can also use this information for troubleshooting wizard purposes.

The following settings are still needed:

- LDevCtx to enable the selection of LDevVip during graph instantiation

- LIfCtx to enable the selection of LIf during graph instantiation

- Bridge domain in LIfCtx

- Route peering in LIfCtx

- Subnet in LIfCtx

About Layer 4 to Layer 7 Services Endpoint Groups

As part of unmanaged mode feature, the Application Policy Infrastructure Controller (APIC) enables you to specify an endpoint group to be used for the graph connector during graph instantiation. This enables you to better troubleshoot the graph deployment. The APIC uses the Layer 4 to Layer 7 services endpoint group that you specified to download encapsulation information to a leaf. The APIC also uses the endpoint group to create port groups on the distributed virtual switch for virtual devices. A Layer 4 to Layer 7 services endpoint group is also used to aggregate faults and statistics information for a graph connector.

In addition to the enhanced visibility into the deployed graph resources, a Layer 4 to Layer 7 services endpoint group can also be used to specify static encapsulation to be used for a specific graph instance. This encapsulation can also be shared across multiple graph instances by sharing the Layer 4 to Layer 7 services endpoint group across multiple graph instances.

For example XML code that shows how you can use a Layer 4 to Layer 7 services endpoint group with a graph connector, see Example XML of Associating a Layer 4 to Layer 7 Service Endpoint Group with a Connector.

Using Static Encapsulation for a Graph Connector

The Application Policy Infrastructure Controller (APIC) allocates the encapsulation for various service graphs during processing. In some use cases, you want to be able explicitly to specify the encapsulation to be used for a specific connector in the service graph. This is known as static encapsulation. Static encapsulations are only supported for the service graph connector that has a service device cluster with physical services. Service device clusters with virtual service devices use the dynamically allocated VLANs from the VMware domain that is associated with the service device cluster.

A static encapsulation can be used with a graph connector by specifying the encapsulation value as part of the Layer 4 to Layer 7 service endpoint group. For example XML code that shows how you can use a static encapsulation with a Layer 4 to Layer 7 services endpoint group, see Example XML of Using Static Encapsulation with a Layer 4 to Layer 7 Service Endpoint Group.

Creating a Physical Device Using the NX-OS-Style CLI

This example procedure creates a physical device using the NX-OS-style CLI.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Create a cluster:

Example:

apic1(config-tenant)# l4l7 cluster name ifav108-asa type physical vlan-domain phyDom5 servicetype FW

Step 4

Add a cluster device:

Example:

apic1(config-cluster)# cluster-device C1

Step 5

Add a provider cluster interface:

Example:

apic1(config-cluster)# cluster-interface provider

Step 6

Add a member device to the interface:

Example:

apic1(config-cluster-interface)# member device C1 device-interface Po1
apic1(config-member)# interface vpc VPCPolASA leaf 103 104
apic1(config-member)# exit
apic1(config-cluster-interface)# exit

Step 7

Add a consumer cluster interface:

Example:

apic1(config-cluster)# cluster-interface consumer

Step 8

Add the same member device to the consumer interface:

Example:

apic1(config-cluster-interface)# member device C1 device-interface Po1
apic1(config-member)# interface vpc VPCPolASA leaf 103 104
apic1(config-member)# exit
apic1(config-cluster-interface)# exit

Step 9

Exit out of the cluster creation mode:

Example:

apic1(config-cluster)# exit

Creating a High Availablity Cluster Using the NX-OS-Style CLI

This example procedure creates a high availability cluster using the NX-OS-style CLI.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Create a cluster:

Example:

apic1(config-tenant)# l4l7 cluster name ifav108-asa type physical vlan-domain phyDom5 servicetype FW

Step 4

Add the cluster devices:

Example:

apic1(config-cluster)# cluster-device C1
apic1(config-cluster)# cluster-device C2

Step 5

Add a provider cluster interface:

Example:

apic1(config-cluster)# cluster-interface provider vlan 101

Step 6

Add member devices to the interface:

Example:

apic1(config-cluster-interface)# member device C1 device-interface Po1
apic1(config-member)# interface vpc VPCPolASA leaf 103 104
apic1(config-member)# exit
apic1(config-cluster-interface)# exit
apic1(config-cluster-interface)# member device C2 device-interface Po2
apic1(config-member)# interface vpc VPCPolASA-2 leaf 103 104
apic1(config-member)# exit
apic1(config-cluster-interface)# exit

Step 7

Add another provider cluster interface:

Example:

apic1(config-cluster)# cluster-interface provider vlan 102

Step 8

Add the same member devices from the first interface to this new interface:

Example:

apic1(config-cluster-interface)# member device C1 device-interface Po1
apic1(config-member)# interface vpc VPCPolASA leaf 103 104
apic1(config-member)# exit
apic1(config-cluster-interface)# exit
apic1(config-cluster-interface)# member device C2 device-interface Po2
apic1(config-member)# interface vpc VPCPolASA-2 leaf 103 104
apic1(config-member)# exit
apic1(config-cluster-interface)# exit

Step 9

Exit out of the cluster creation mode:

Example:

apic1(config-cluster)# exit

Creating a Virtual Device Using the NX-OS-Style CLI

This example procedure creates a virtual device using the NX-OS-style CLI.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Create a cluster:

Example:

apic1(config-tenant)# l4l7 cluster name ifav108-citrix type virtual vlan-domain ACIVswitch servicetype ADC

Step 4

Add a cluster device:

Example:

apic1(config-cluster)# cluster-device D1 vcenter ifav108-vcenter vm NSVPX-ESX

Step 5

Add a consumer cluster interface:

Example:

apic1(config-cluster)# cluster-interface consumer

Step 6

Add a member device to the consumer interface:

Example:

apic1(config-cluster-interface)# member device D1 device-interface 1_1
apic1(config-member)# interface ethernet 1/45 leaf 102
ifav108-apic1(config-member)# vnic "Network adapter 2"
apic1(config-member)# exit
apic1(config-cluster-interface)# exit

Step 7

Add a provider cluster interface:

Example:

apic1(config-cluster)# cluster-interface provider

Step 8

Add the same member device to the provider interface:

Example:

apic1(config-cluster-interface)# member device D1 device-interface 1_1
apic1(config-member)# interface ethernet 1/45 leaf 102
ifav108-apic1(config-member)# vnic "Network adapter 2"
apic1(config-member)# exit
apic1(config-cluster-interface)# exit

Step 9

Exit out of the cluster creation mode:

Example:

apic1(config-cluster)# exit

Example XML for the Unmanaged Mode

The example XML in the following sections show how to administer the unmanaged mode.

- Example XML of Creating an Unmanaged LDevVip Object

- Example XML of Creating an Unmanaged AbsNode Object

- Example XML of Associating a Layer 4 to Layer 7 Service Endpoint Group with a Connector

- Example XML of Using Static Encapsulation with a Layer 4 to Layer 7 Service Endpoint Group

Example XML of Creating an Unmanaged LDevVip Object

The following example XML creates an unmanaged LDevVip object:

<polUni>
<fvTenant name="HA_Tenant1">
<vnsLDevVip name="ADCCluster1" devtype="VIRTUAL" managed="no">
<vnsRsALDevToDomP tDn="uni/vmmp-VMware/dom-mininet"/>
</vnsLDevVip>
</fvTenant>
</polUni>

Example XML of Creating an Unmanaged AbsNode Object

The following example XML creates an unmanaged AbsNode object:

<fvTenant name="HA_Tenant1">
<vnsAbsGraph name="g1">
<vnsAbsTermNodeProv name="Input1">
<vnsAbsTermConn name="C1">
</vnsAbsTermConn>
</vnsAbsTermNodeProv>

<!-- Node1 provides a service function in un-managed mode -->
<vnsAbsNode name="Node1" managed="no">
<vnsAbsFuncConn name="outside" >
</vnsAbsFuncConn>
<vnsAbsFuncConn name="inside" >
</vnsAbsFuncConn>
</vnsAbsNode>

<vnsAbsTermNodeCon name="Output1">
<vnsAbsTermConn name="C6">
</vnsAbsTermConn>
</vnsAbsTermNodeCon>

<vnsAbsConnection name="CON2" >
<vnsRsAbsConnectionConns tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsTermNodeCon-Output1/AbsTConn"/>
<vnsRsAbsConnectionConns tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsNode-Node1/AbsFConn-outside"/>
</vnsAbsConnection>

<vnsAbsConnection name="CON1" >
<vnsRsAbsConnectionConns tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsNode-Node1/AbsFConn-inside"/>
<vnsRsAbsConnectionConns tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsTermNodeProv-Input1/AbsTConn"/>
</vnsAbsConnection>

</vnsAbsGraph>
</fvTenant>

Example XML of Associating a Layer 4 to Layer 7 Service Endpoint Group with a Connector

The following example XML associates a Layer 4 to Layer 7 service endpoint group with a connector:

<fvTenant name="HA_Tenant1">
<vnsLDevCtx ctrctNameOrLbl="any" descr="" dn="uni/tn-HA_Tenant1/ldevCtx-c-any-g-any-n-any"
graphNameOrLbl="any" name="" nodeNameOrLbl="any">
<vnsRsLDevCtxToLDev tDn="uni/tn-HA_Tenant1/lDevVip-ADCCluster1"/>
<vnsLIfCtx connNameOrLbl="inside" descr="" name="inside">
<vnsRsLIfCtxToSvcEPg tDn="uni/tn-HA_Tenant1/ap-sap/SvcEPg-EPG1"/>
<vnsRsLIfCtxToBD tDn="uni/tn-HA_Tenant1/BD-provBD1"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-HA_Tenant1/lDevVip-ADCCluster1/lIf-inside"/>
</vnsLIfCtx>
<vnsLIfCtx connNameOrLbl="outside" descr="" name="outside">
<vnsRsLIfCtxToSvcEPg tDn="uni/tn-HA_Tenant1/ap-sap/SvcEPg-EPG2"/>
<vnsRsLIfCtxToBD tDn="uni/tn-HA_Tenant1/BD-consBD1"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-HA_Tenant1/lDevVip-ADCCluster1/lIf-outside"/>
</vnsLIfCtx>
</vnsLDevCtx>
</fvTenant>

Example XML of Using Static Encapsulation with a Layer 4 to Layer 7 Service Endpoint Group

The following example XML uses static encapsulation with a Layer 4 to Layer 7 service endpoint group:

<polUni>
<fvTenant name="HA_Tenant1">
<fvAp name="sap">
<vnsSvcEPg name="EPG1" encap="vlan-3510">
</vnsSvcEPg>
</fvAp>
</fvTenant>
</polUni>

Unmanaged Mode Behavior

The following behavior applies regarding the unmanaged mode:

- Parameter resolution and unmanaged functions—For an unmanaged function, the Application Policy Infrastructure Controller (APIC) does not perform parameter resolution. Parameters are not required to be configured on AbsGraph, an endpoint group, or any other level.

- VDev and unmanaged functions— For an unmanaged function, the APIC does not perform parameter resolution or device side programming. No VDev tree is created for an unmanaged service graph function.

- Route peering in unmanaged mode—Unmanaged mode does not impact route peering functionality.

- VNIC auto-placement in unmanaged mode—Unmanaged mode does not impact VNIC placement functionality.

Chapter 11. Configuration Parameters

- Configuration Parameters Inside the Device Package Specification

- Configuration Parameters Inside An Abstract Function Profile

- Configuration Parameters Inside an Abstract Function Node in a Service Graph

- Configuration Parameters Inside Various Configuration MOs

- Parameter Resolution

- Looking Up an MO During Parameter Resolution

- About Role-Based Access Control Rule Enhancements

Configuration Parameters Inside the Device Package Specification

A device package contains an XML file that describes the specification for the service device. This specification includes device information as well as various functions provided by the service device.

As part of the device specification, this file must contain the declaration for the configuration needed by the service device. This configuration is needed to configure various functions that are provided by the service device during graph instantiation.

The following figure shows the configuration parameters hierarchy inside the device package.

Configuration Parameters Hierarchy Inside the Device Package

MFolder

MFolder is a group of configuration items that can contain MParams and other nested MFolders. An MFolder has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value of cardinality is 1. If cardinality is N, The Application Policy Infrastructure Controller (APIC) allows N instances of the configuration parameter to be configured.

ScopedBy

Specifies the scope for the parameter resolution. ScopedBy determines where to look for parameter values when APIC resolves the parameter from configuration MOs.

Default value is Epg. Supported values are Tenant, Ap, Bd, and Epg.

RsConnector

A relation that associates a configuration item to an MConn.

DevCtx

Allows a configuration item to be associated with a specific physical device (CDev) in a device (LDev).

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

MParam

MParam is the basic unit of configuration parameters that declares a single configuration parameter. MParam has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value of cardinality is 1. If cardinality is N, The APIC allows N instances of the configuration parameter to be configured.

RsConnector

A relation that associates a configuration item to an MConn.

Mandatory

Allows a configuration item to be marked as mandatory.

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

Validation

Specifies the validation method for the value.

MRel

MRel allows one MFolder to refer to another MFolder. Using MRel inside an MFolder, an administrator can associate the containing MFolder to the MFolder that is pointed by the MRel using the RsTarget relation contained inside MRel. MRel has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value of cardinality is 1.

RsTarget

A relation that associates a configuration folder to another MFolder. The value of TDn for this relation is the DN of the target folder.

RsConnector

A relation that associates a configuration item to an MConn.

Mandatory

Allows a configuration item to be marked as mandatory.

- Configuration Scope of a Device Package Specification

- Example XML of Configuration Parameters Inside the Device Package

Configuration Scope of a Device Package Specification

In a device specification file, configuration items are arranged in different sections.

MDevCfg

The MDevCfg section describes the device level configuration, which is shared by all service graphs using the device. The Application Policy Infrastructure Controller (APIC) does a reference counting of the configuration objects created by using the configuration items described in this section. Objects are only deleted from a service device after all the graph instances that use the device are deleted.

MFuncCfg

The MFuncCfg describes the configuration that is local to a service function and is specific to a service function. The APIC does a reference counting of the configuration objects created by the configuration items described in this section. Objects are created and deleted whenever a service function is instantiated and deleted.

MGrpCfg

The MGrpCfg describes the configuration that is shared by all functions of a service graph using the device. The APIC does a reference counting of the configuration objects created by using the configuration items described in this section. Objects are only deleted from a service device after all functions from the service graph are deleted.

Example XML of Configuration Parameters Inside the Device Package

The following XML example shows configuration parameters inside of the device package:

<vnsMFolder key="VServer" scopedBy="epg">
<vnsRsConnector tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB/mConn-external"/>
<vnsMParam key="vservername" description="Name of VServer" mandatory="true"/>
<vnsMParam key="vip" description="Virtual IP"/>
<vnsMParam key="subnet" description="Subnet IP"/>
<vnsMParam key="port" description="Port for Virtual server"/>
<vnsMParam key="persistencetype" description="persistencetype"/>
<vnsMParam key="servicename" description="Service bound to this vServer"/>
<vnsMParam key="servicetype" description="Service bound to this vServer"/>
<vnsMParam key="clttimeout" description="Client timeout"/>
<vnsMFolder key="VServerGlobalConfig"
description="This references the global configuration">
<vnsMRel key="ServiceConfig">
<vnsRsTarget tDn="uni/infra/mDev-Acme-ADC-1.0/mDevCfg/mFolder-Service"/>
</vnsMRel>
<vnsMRel key="ServerConfig">
<vnsRsTarget tDn="uni/infra/mDev-Acme-ADC-1.0/mDevCfg/mFolder-Server"/>
</vnsMRel>
<vnsMRel key="VipConfig">
<vnsRsTarget
tDn="uni/infra/mDev-Acme-ADC-1.0/mDevCfg/mFolder-Network/mFolder-vip"/>
<vnsRsConnector tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB/mConn-external"/>
</vnsMRel>
</vnsMFolder>
</vnsMFolder>

Configuration Parameters Inside An Abstract Function Profile

An abstract profile allows an administrator to configure the default values for the configuration parameters. An abstract function profile contains configuration parameters with values. These values are used as default values during graph instantiation.

An abstract function profile is attached to a function node in a service graph. The default values specified in an abstract function profile is then used when rendering the function onto the service device at the graph instantiation time.

The following figure shows the configuration parameters hierarchy within an abstract function profile.

Configuration Parameters Hierarchy Within an Abstract Function Profile

AbsFolder

AbsFolder is a group of configuration items that can contain AbsParams and other nested AbsFolders. For each AbsFolder, there must be an MFolder inside the device package. The Application Policy Infrastructure Controller (APIC) validates each AbsFolder to ensure that the AbsFolder has a corresponding MFolder in the package. An AbsFolder has the following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value is 1.

ScopedBy

Specifies the scope for the parameter resolution. ScopedBy determines where to look for parameter values when the APIC resolves the parameter from configuration MOs.

Default value is Epg. Supported values are Tenant, Ap, Bd, and Epg.

DevCtx

Allows a configuration item to be associated with a specific physical device (CDev) in a device cluster (LDev).

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

AbsParam

AbsParam is the basic unit of configuration parameters. AbsParam defines a single configuration parameter. As with an AbsFolder, each AbsParam must have an equivalent MFolder in the device specification. The APIC validates the specification to ensure that AbsParam has a corresponding MFolder in the package. The value of an AbsParam is validated using the validation method specified in MParam. An AbsParam has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Value

Holds the value for a given configuration item. Values are not supported for MParam.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value is 1.

Mandatory

Allows a configuration item to be marked as mandatory.

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

Validation

Specifies the validation mechanism to be used to validate the configuration parameter.

AbsRel

AbsRel allows one AbsFolder to refer to another AbsFolder. An AbsRel has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Value

Holds the value for a given configuration item. Values are not supported for MParam.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value is 1.

Mandatory

Allows a configuration item to be marked as mandatory.

- Configuration Scope of an Abstract Function Profile

- Example XML POST for an Abstract Function Profile With Configuration Parameters

Configuration Scope of an Abstract Function Profile

Within an abstract function profile, the configuration parameters are structured in a similar manner as to how they are structured inside a device package. There are three different scopes.

AbsDevCfg

This section provides the default value for the configuration items that are declared to be the device level configuration inside of a device package. The configuration items are specified under MDevCfg.

For each configuration item, there must be an equivalent configuration item under the device package.

The configuration that is described in this section is shared by all service graphs that use the device. The Application Policy Infrastructure Controller (APIC) does a reference counting of the configuration objects that are created by using the configuration items that are described in this section. Objects are only deleted from a service device after all graph instances that are using the device are deleted.

AbsGrpCfg

This section provides the default value for the configuration items that are declared to be the device level configuration inside of a device package. The configuration items are specified under MGrpCfg.

For each configuration item, there must be an equivalent configuration item under the device package.

The configuration described in this section is shared by all functions of a service graph that use the device. The APIC does a reference counting of the configuration objects that are created by using the configuration items that are described in this section. Objects are only deleted from a service device after all graph instances that are using the device are deleted.

AbsFuncCfg

This section provides the default value for the configuration items that are declared to be the function level configuration inside of a device package. The configuration items are specified under MFuncCfg.

For each configuration item, there must be an equivalent configuration item under the device package.

This section is used to describe the configuration that is local to a service function. The configuration described in this section is specific to a service function. The APIC does a reference counting of the configuration objects that are created by the configuration items that are described in this section. Objects are created and deleted whenever a service function is instantiated and deleted.

Example XML POST for an Abstract Function Profile With Configuration Parameters

The following XML POST example shows an abstract function profile with configuration parameters:

<vnsAbsFuncProfContr name = "NP">
<vnsAbsFuncProfGrp name = "Grp1">
<vnsAbsFuncProf name = "P1">
<vnsRsProfToMFunc tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB"/>
<vnsAbsDevCfg name="D1">
<vnsAbsFolder key="Service" name="Service-Default" cardinality="n">
<vnsAbsParam name="servicetype" key="servicetype" value="TCP"/>
<vnsAbsParam name="serviceport" key="serviceport" value="80"/>
<vnsAbsParam name="maxclient" key="maxclient" value="1000"/>
<vnsAbsParam name="maxreq" key="maxreq" value="100"/>
<vnsAbsParam name="cip" key="cip" value="enable"/>
<vnsAbsParam name="usip" key="usip" value="enable"/>
<vnsAbsParam name="sp" key="sp" value=""/>
<vnsAbsParam name="svrtimeout" key="svrtimeout" value="60"/>
<vnsAbsParam name="clttimeout" key="clttimeout" value="60"/>
<vnsAbsParam name="cka" key="cka" value="NO"/>
<vnsAbsParam name="tcpb" key="tcpb" value="NO"/>
<vnsAbsParam name="cmp" key="cmp" value="NO"/>
</vnsAbsFolder>
</vnsAbsDevCfg>
<vnsAbsFuncCfg name="SLB">
<vnsAbsFolder key="VServer" name="VServer-Default">
<vnsAbsParam name="port" key="port" value="80"/>
<vnsAbsParam name="persistencetype" key="persistencetype"
value="cookie"/>
<vnsAbsParam name="clttimeout" key="clttimeout" value="100"/>
<vnsAbsParam name="servicetype" key="servicetype" value="TCP"/>
<vnsAbsParam name="servicename" key="servicename"/>
</vnsAbsFolder>
</vnsAbsFuncCfg>
</vnsAbsFuncProf>
</vnsAbsFuncProfGrp>
</vnsAbsFuncProfContr>

Configuration Parameters Inside an Abstract Function Node in a Service Graph

A function node inside a service graph allows an administrator to configure values for the configuration parameters. These values are used during graph instantiation.

Within an abstract function node, the configuration parameters are structured in a similar manner as to how they are structured inside an abstract function profile.

The following figure shows the configuration parameters hierarchy inside an abstract function node.

Configuration Parameters Hierarchy Inside an Abstract Function Node

AbsDevCfg

This section is used to provide the default value for the configuration items that are declared to be the device level configuration inside of the device package. The configuration items are specified under MDevCfg.

For each of these configuration items, there must be an equivalent configuration item under the device package.

AbsGrpCfg

This section is used to provide the default value for the configuration items that are declared to be the device level configuration inside of the device package. The configuration items are specified under MGrpCfg.

For each of these configuration items, there must be an equivalent configuration item under the device package.

The configuration that is described in this section is shared by all functions of a service graph that use the device. The Application Policy Infrastructure Controller (APIC) does a reference counting of the configuration objects that are created by using the configuration items that are described in this section. Objects are only deleted from a service device after all functions from the service graph are deleted.

AbsFuncCfg

This section is used to provide the default value for the configuration items that are declared to be the function level configuration inside of the device package. The configuration items are specified under MFuncCfg.

For each of these configuration items, there must be an equivalent configuration item under the device package.

This section is used to describe the configuration that is local to a service function. The configuration that is described in this section is specific to a service function. The APIC does a reference counting of the configuration objects that are created by the configuration items that are described in this section. Objects are created and deleted whenever a service function is instantiated and deleted.

AbsFolder

AbsFolder is a group of configuration items that can contain AbsParamss and other nested AbsFolders. For each AbsFolder, there must be an MFolder inside the device package. The APIC validates each AbsFolder to ensure that the AbsFolder has a corresponding MFolder in the package. AbsFolder has the following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value is 1.

ScopedBy

Specifies the scope for the parameter resolution. ScopedBy determines where to look for parameter values when the APIC resolves the parameter from configuration MOs.

Default value is Epg. Supported values are Tenant, Ap, Bd, and Epg.

RsCfgToConn

A relation that associates a configuration item to an AbsConn.

DevCtx

Allows a configuration item to be associated with a specific physical device (CDev) in a device (LDev).

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

AbsParam

AbsParam is the basic unit of configuration parameters. AbsParam defines a single configuration parameter. As with an AbsFolder, each AbsParam must have an equivalent MFolder in the device specification. The APIC validates the specification to ensure that AbsParam has a corresponding MFolder in the package. The value of an AbsParam is validated using the validation method specified in MParam. AbsParam has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Value

Holds the value for a given configuration item. Values are not supported for MParam.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value is 1.

RsCfgToConn

A relation that associates a configuration item to an MConn.

Mandatory

Allows a configuration item to be marked as mandatory.

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

Validation

Specifies the validation mechanism to be used to validate the configuration parameter.

AbsRel

AbsRel allows one AbsFolder to refer to another AbsFolder. AbsRel has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Value

Holds the value for a given configuration item. Values are not supported for MParam.

Description

Describes the configuration item.

Cardinality

Specifies the cardinality of the configuration item. The default value is 1.

RsCfgToConn

A relation that associates a configuration item to an MConn.

Mandatory

Allows a configuration item to be marked as mandatory.

Locked

Allows a configuration item value to be locked. Once locked, the value cannot be changed.

- Example XML POST for an Abstract Function Node With Configuration Parameters

Example XML POST for an Abstract Function Node With Configuration Parameters

The following XML POST example shows an abstract function node with configuration parameters:

<vnsAbsNode name = "SLB" funcType="GoTo" >
<vnsRsDefaultScopeToTerm tDn="uni/tn-tenant1/AbsGraph-G3/AbsTermNode-Output1/outtmnl"/>
<vnsAbsFuncConn name = "C4" direction = "input">
<vnsRsMConnAtt tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB/mConn-external" />
</vnsAbsFuncConn>
<vnsAbsFuncConn name = "C5" direction = "output">
<vnsRsMConnAtt tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB/mConn-internal" />
</vnsAbsFuncConn>

<vnsAbsDevCfg>
<vnsAbsFolder key="Network" name="Network" scopedBy="epg">
<!-- Following scopes this folder to input terminal or Src Epg -->
<vnsRsScopeToTerm tDn="uni/tn-tenant1/AbsGraph-G3/AbsTermNode-Output1/outtmnl"/>

<!-- VIP address -->
<vnsAbsFolder key="vip" name="vip" scopedBy="epg">
<vnsAbsParam name="vipaddress" key="vipaddress" value=""/>
</vnsAbsFolder>

<!-- SNIP address -->
<vnsAbsFolder key="snip" name="snip" scopedBy="epg">
<vnsAbsParam name="snipaddress" key="snipaddress" value=""/>
</vnsAbsFolder>

</vnsAbsFolder>

<vnsAbsFolder key="Service" name="Service" scopedBy="epg" cardinality="n">
<vnsRsScopeToTerm tDn="uni/tn-tenant1/AbsGraph-G3/AbsTermNode-Output1/outtmnl"/>
<vnsAbsParam name="servicename" key="servicename" value=""/>
<vnsAbsParam name="servername" key="servername" value=""/>
<vnsAbsParam name="serveripaddress" key="serveripaddress" value=""/>
</vnsAbsFolder>
</vnsAbsDevCfg>

<vnsAbsFuncCfg>
<vnsAbsFolder key="VServer" name="VServer" scopedBy="epg">
<vnsRsScopeToTerm tDn="uni/tn-tenant1/AbsGraph-G3/AbsTermNode-Output1/outtmnl"/>
<!-- Virtual Server Configuration -->
<vnsAbsParam name="vip" key="vip" value=""/>
<vnsAbsParam name="vservername" key="vservername" value=""/>
<vnsAbsParam name="servicename" key="servicename"/>
<vnsRsCfgToConn tDn="uni/tn-tenant1/AbsGraph-G3/AbsNode-Node2/AbsFConn-C4" />
</vnsAbsFolder>
</vnsAbsFuncCfg>
<vnsRsNodeToMFunc tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB"/>
</vnsAbsNode>

Configuration Parameters Inside Various Configuration MOs

An administrator can specify configuration parameters for a service function as part of various Application Policy Infrastructure Controller (APIC) MOs, such as EPG, tenant, BD, or AP. When a graph is instantiated, the APIC resolves the needed configuration for a graph by looking up the parameters from various places. At instantiation, parameter values are resolved and passed to the device script.

The flexibility of being able to keep configuration parameters inside various MOs allows an administrator to configure a single service graph and then use the graph for different tenants or end point groups (EPGs) with a different configuration for different tenants or EPGs.

The following figure shows the hierarchy of an APIC MO.

Hierarchy of an APIC MO

The following figure shows configuration parameters inside various configuration MOs.

Configuration Parameters Inside Various Configuration MOs

FolderInst

FolderInst is a group of configuration items that can contain ParamInsts and other nested FolderInsts. A FolderInst has the following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

ctrctNameOrLbl

Finds a matching FolderInst during parameter resolution. For a FolderInst to be used for parameter resolution, this property must match with the name of the contract that is associated with the service graph. Otherwise, this FolderInst is skipped and values are not used from this FolderInst.

The value of this field can be "any" to allow this FolderInst to be used for all contracts.

graphNameOrLbl

Finds a matching FolderInst during parameter resolution. For a FolderInst to be used for parameter resolution, this property must match with the service graph name. Otherwise, this FolderInst is skipped and values are not used from this FolderInst.

The value of this field can be “any” to allow this FolderInst to be used for all service graphs.

nodeNameOrLbl

Finds a matching FolderInst during parameter resolution. For a FolderInst to be used for parameter resolution, this property must match with the node name. Otherwise, this FolderInst is skipped and values are not used from this FolderInst.

The value of this field can be “any” to allow this FolderInst to be used for all nodes in a service graph.

ParamInst

ParamInst is the basic unit of configuration parameters. ParamInst defines a single configuration parameter. As with a FolderInst, each ParamInst must have an equivalent MParam in the device specification. The APIC validates the specification to ensure that ParamInst has a corresponding MParam in the package. The value of an ParamInst is validated using the validation method specified in the corresponding MParam. ParamInst has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Value

Holds the value for a given configuration item. Values are not supported for MParam.

CfgRelInst

CfgRelInst has following attributes:

Attribute

Description

Key

Defines the type of the configuration item. The key is defined in the device package and can never be overwritten. The key is used as a matching criterion as well as for validation.

Value

Holds the path for the target FolderInst.

- Example XML POST for an Application EPG With Configuration Parameters

Example XML POST for an Application EPG With Configuration Parameters

The following XML example shows configuration parameters inside of the device package:

<fvAEPg dn="uni/tn-acme/ap-myApp/epg-app"  name="app">

<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any" key="Monitor"
name="monitor1">
<vnsRsFolderInstToMFolder tDn="uni/infra/mDev-Acme-ADC-1.0/mDevCfg/mFolder-Monitor"/>
<vnsParamInst name="weight" key="weight" value="10"/>
</vnsFolderInst>

<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any" key="Service"
name="Service1">
<vnsParamInst name="servicename" key="servicename" value="crpvgrtst02-8010"/>
<vnsParamInst name="servicetype" key="servicetype" value="TCP"/>
<vnsParamInst name="servername" key="servername" value="s192.168.100.100"/>
<vnsParamInst name="serveripaddress" key="serveripaddress" value="192.168.100.100"/>
<vnsParamInst name="serviceport" key="serviceport" value="8080"/>
<vnsParamInst name="svrtimeout" key="svrtimeout" value="9000" />
<vnsParamInst name="clttimeout" key="clttimeout" value="9000" />
<vnsParamInst name="usip" key="usip" value="NO" />
<vnsParamInst name="useproxyport" key="useproxyport" value="" />
<vnsParamInst name="cip" key="cip" value="ENABLED" />
<vnsParamInst name="cka" key="cka" value="NO" />
<vnsParamInst name="sp" key="sp" value="OFF" />
<vnsParamInst name="cmp" key="cmp" value="NO" />
<vnsParamInst name="maxclient" key="maxclient" value="0" />
<vnsParamInst name="maxreq" key="maxreq" value="0" />
<vnsParamInst name="tcpb" key="tcpb" value="NO" />
<vnsCfgRelInst name="MonitorConfig" key="MonitorConfig" targetName="monitor1"/>
</vnsFolderInst>

<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G2" nodeNameOrLbl="any" key="Network"
name="Network">
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G2" nodeNameOrLbl="any" key="vip"
name="vip">
<vnsParamInst name="vipaddress1" key="vipaddress" value="10.10.10.200"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G2" nodeNameOrLbl="any"
devCtxLbl="C1" key="snip" name="snip1">
<vnsParamInst name="snipaddress" key="snipaddress" value="192.168.1.200"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G2" nodeNameOrLbl="any"
devCtxLbl="C2" key="snip" name="snip2">
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G1" nodeNameOrLbl="any" key="Network"
name="Network">
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G1" nodeNameOrLbl="any" key="vip"
name="vip">
<vnsParamInst name="vipaddress1" key="vipaddress" value="10.10.10.100"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G1" nodeNameOrLbl="any"
devCtxLbl="C1" key="snip" name="snip1">
<vnsParamInst name="snipaddress" key="snipaddress" value="192.168.1.100"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G1" nodeNameOrLbl="any"
devCtxLbl="C2" key="snip" name="snip2">
<vnsParamInst name="snipaddress" key="snipaddress" value="192.168.1.101"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="G1" nodeNameOrLbl="any"
devCtxLbl="C3" key="snip" name="snip3">
<vnsParamInst name="snipaddress" key="snipaddress" value="192.168.1.102"/>
</vnsFolderInst>
</vnsFolderInst>

<!-- SLB Configuration -->
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any" key="VServer"
name="VServer">
<!-- Virtual Server Configuration -->
<vnsParamInst name="port" key="port" value="8010"/>
<vnsParamInst name="vip" key="vip" value="10.10.10.100"/>
<vnsParamInst name="vservername" key="vservername" value="crpvgrtst02-vip-8010"/>
<vnsParamInst name="servicename" key="servicename" value="crpvgrtst02-8010"/>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any"
key="VServerGlobalConfig" name="VServerGlobalConfig">
<vnsCfgRelInst name="ServiceConfig" key="ServiceConfig" targetName="Service1"/>
<vnsCfgRelInst name="VipConfig" key="VipConfig" targetName="Network/vip"/>
</vnsFolderInst>
</vnsFolderInst>
</fvAEPg>

Parameter Resolution

During graph instantiation, the Application Policy Infrastructure Controller (APIC) resolves the configuration parameters for each function in the service graph. After resolution completes, the parameter values are passed to the device script. The device script uses these parameter values to configure the service on the service appliance.

The following flow chart describes the parameter resolution steps.

Parameter Resolution

Looking Up an MO During Parameter Resolution

The Application Policy Infrastructure Controller (APIC) uses two main constructs while finding the suitable configuration MO to take the configuration parameters from.

RsScopeToTerm

The RsScopeToTerm relation for a function node or for an AbsFolder indicates the terminal node of the service graph that is connected with the configuration MOs that has parameters for the graph. The APIC uses the configuration MOs that are connected to the specified terminal node in RsScopeToTerm to find the graph configuration parameters.

If there is no RsScopeToTerm configuration specified, APIC uses the terminal connected to the provider EPG by default.

ScopedBy Attribute

The ScopedBy attribute is used to find the starting MO from which to resolve the parameter. For example, if scopedBy has a value of "Epg", the APIC starts the parameter resolution from the endpoint group. The APIC then walks up in the hierarchy to resolve the parameters, walking to the application profile and then to the tenant to resolve the configuration parameters.

The following figure shows the hierarchy of an APIC MO.

Hierarchy of an APIC MO

About Role-Based Access Control Rule Enhancements

Layer 4 to Layer 7 policy configurations in a multi-tenant environment required administrator intervention to create certain objects that cannot be created by tenant administrators using the classic role-based access control (RBAC) domains and roles model definition. An Application Policy Infrastructure Controller (APIC) provides more granular RBAC privileges in the management information tree (MIT) such that you can grant tenant administrators the privileges that are required to create the objects. Tenant administrators can also create RBAC rules through self-service without administrator intervention to grant permissions for resources under their tenant subtree to other tenants and users in the system.

- Role-Based Access Control Rule Architecture

- Role-Based Access Control Rule System Flow

Role-Based Access Control Rule Architecture

The role-based access control (RBAC) rule has a boolean field allowWrites that enhances the role-based access control (RBAC) model to allow writeability rules. Without the allowWrites field, you can only define read RBAC rules.

The RbacRule class is defined as follows:

Class aaa:RbacRule (CONCRETE)
Encrypted: false
Exportable: true
Persistent: true
Configurable: true
Write Access: [aaa, admin]
Read Access: [aaa, admin]

An RBAC rule allows users from a security domain to read the subtree starting at a specific object.

DN FORMAT:   [1] uni/rbacdb/rule-{[objectDn]}-dom-{domain}

aaa:RbacRule Properties Summary

Property

Type

Class

Description

aaa:Boolean

scalar:Enum8

allowWrites (aaa:RbacRule:allowWrites)

Read-write or read rule.

naming:Name

string:Basic

domain (aaa:RbacRule:domain)

The domain of the counts object. Overrides aaa:ARbacRule:domain.

reference:BinRef

objectDn (aaa:RbacRule:objectDn)

Overrides aaa:ARbacRule:objectDn.

The PartialRbacRule class is defined under the fvTenant class to allow tenants to create RBAC Rules (self-service). The PartialRbacRule class is defined as follows:

Class aaa:PartialRbacRule (CONCRETE)
Encrypted: false
Exportable: true
Persistent: true
Configurable: true
Write Access: [aaa, admin]
Read Access: [aaa, admin]

aaa:PartialRbacRule Properties Summary

Property

Type

Class

Description

aaa:Boolean

scalar:Enum8

allowWrites (aaa:PartialRbacRule:allowWrites)

Read-write or read rule.

naming:Name

string:Basic

domain (aaa:PartialRbacRule:domain)

The domain of the counts object.

reference:BinRef

monPolDn (aaa:PartialRbacRule:monPolDn)

The monitoring policy attached to this observable object.

reference:BinRef

partialObjectDn (aaa:PartialRbacRule:partialObjectDn)

The creation of the PartialRbacRule class by the tenant must be checked for a legal partialObjectDn. If the partialObjectDn lies under the tenant subtree, it is legal. Any distinguished names outside of the parent tenant subtree are not permitted.

The administrator can create RbacRules that point to any distinguished name in the system. The tenant administrator can only create PartialRbacRules that point to distinguished names that lie in that tenant administrator's tenant subtree.

Role-Based Access Control Rule System Flow

Either before, during, or after configuring the Layer 4 to Layer 7 policy, the tenant administrator can choose to create PartialRbacRules that grant access to specific firewall and load balancer devices to their own tenant users. The access is implemented by creating aaaDomains that represent each resource group that must be individually assigned. The following information provides an example setup:

Tenant

Acme

Users

acme-admin

acme-firewall-1-admin

acme-firewall-2-admin

acme-loadbalancer-1-admin

acme-loadbalancer-2-admin

Firewall Devices

Firewall1

Firewall2

Load Balancer Devices

LB1

LB2

The tenant administrator user acme-admin wishes to create the devices Firewall1, Firewall2, LB1, and LB2. Full write permissions for each device need to be assigned on an individual user basis. For example, user acme-firewall-1-admin must only have write privileges to device Firewall1 policies, while user acme-loadbalancer-1-admin must only have write privileges to device LB1 policies. To accomplish this, the acme-admin user creates 4 PartialRbacRules that grant the following access:

- Firewall1 distinguished name—writeable by domain acme-firewall1

- Firewall2 distinguished name—writeable by domain acme-firewall2

- LB1 distinguished name—writeable by domain acme-lb1

- LB2 distinguished name—writeable by domain acme-lb2

Users are then assigned the following privileges:

- User—acme-firewall-1-admin

- Domain acme—read-all permissions

- Domain acme-firewall1—tenant-admin/write

- User—acme-firewall-2-admin

- Domain acme—read-all permissions

- Domain acme-firewall2—tenant-admin/write

- User—acme-lb-1-admin

- Domain acme—read-all permissions

- Domain acme-lb1—tenant-admin/write

- User—acme-lb-2-admin

- Domain acme—read-all permissions

- Domain acme-lb2—tenant-admin/write

For any of the above 4 users, the domain acme's permissions allow them to read the acme tenant subtree, but not write any nodes. The domain acme-lb2's permissions of tenant-admin/write allow the user to write to the LB2 policy subtree only.

Chapter 12. Using a Service Graph Template

- Associating Service Graph Templates with Contracts and EPGs Using the GUI

- Creating a Service Graph Template Using the NX-OS-Style CLI

- Configuring a Service Graph Template Using the Object Model CLI

- Configuring a Service Graph Template Using the REST APIs

Associating Service Graph Templates with Contracts and EPGs Using the GUI

You must associate the service graph templates with contracts and endpoint groups (EPGs) using the GUI.

Note

You can use only the GUI to associate a service graph template with contracts and EPGs.

See Using the GUI for the procedure for associating service graph templates with contracts and EPGs.

Creating a Service Graph Template Using the NX-OS-Style CLI

The following procedure creates a service graph template.

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enter the configure mode for a tenant.

tenant tenant_name

Example:

apic1(config)# tenant t1

Step 3

Associate a service graph to the template.

l4l7 graph graph_name contract contract_name

Parameter

Description

graph

The name of the service graph template.

contract

The name of the contract to use with the service graph template.

Example:

apic1(config-tenant)# l4l7 graph GraphL3asa contract ContractL3ASA

Step 4

Add a function node.

service node_name [device-cluster-tenant tenant_name] [device-cluster device_name] [mode deployment_mode]

Parameter

Description

service

The name of the service node to add.

device-cluster-tenant

The tenant from which to import the device cluster. Specify this only if the device-cluster is not in the same tenant in which the graph is being configured.

device-cluster

Name of the device cluster to use for this service node.

mode

The deployment mode. Possible values are:

- ADC_ONE_ARM—Specifies one-arm mode.

- ADC_TWO_ARM—Specifies two-arm mode.

- FW_ROUTED—Specifies routed (GoTo) mode.

- FW_TRANS—Specifies transparent (GoThrough) mode.

- OTHERS

If the mode is not specified, then a deployment mode is not used.

Example:

apic1(config-graph)# service Node1 device-cluster-tenant common device-cluster ifav108-asa-2 mode FW_ROUTED

Step 5

Add the consumer connector.

connector connector_type [cluster-interface interface_type]

Parameter

Description

connector

The type of the connector in the service graph. Possible values are:

- provider

- consumer

cluster-interface

The type of the device cluster interface. Possible values are:

- provider

- consumer

Do not specify this parameter if you are a service graph template in tenant Common.

Example:

apic1(config-service)# connector consumer cluster-interface consumer

Step 6

Associate a tenant with the connector and then exit the connector configuration mode.

l4l7-peer tenant tenant_name out L3OutExternal epg epg_name
redistribute redistribute_property
exit

Parameter

Description

tenant

The name of the tenant to associate with the connector.

out

The name of the Layer 3 outside.

epg

The name of the endpoint group.

redistribute

The properties of the redistribute protocol.

Example:

apic1(config-connector)# l4l7-peer tenant t1 out L3OutExternal epg L3ExtNet
redistribute connected,ospf
apic1(config-connector)# exit

Step 7

Repeat steps 5 and 6 for the provider.

Example:

apic1(config-service)# connector provider cluster-interface provider
apic1(config-connector)# l4l7-peer tenant t1 out L3OutInternal epg L3IntNet
redistribute connected,ospf
apic1(config-connector)# exit

Step 8

(Optional) Add a router and then exit the node configuration mode.

rtr-cfg router_ID
exit

Parameter

Description

rtr-cfg

The ID of the router.

Skip this step if you are creating a service graph template in tenant Common.

Example:

apic1(config-service)# rtr-cfg router-id1
apic1(config-service)# exit

Step 9

Associate a connection with a consumer connector and another with a provider connector, and then exit the service graph configuration mode.

connection connection_name terminal terminal_type service node_name
connector connector_type
exit

Parameter

Description

connection

The name of the connection to associate with the connector.

terminal

The type of the terminal. Possible values are:

- provider

- consumer

service

The name of the node of the service graph.

connector

The type of the connector. Possible values are:

- provider

- consumer

Example:

apic1(config-graph)# connection C1 terminal consumer service Node1 connector consumer
apic1(config-graph)# connection C2 terminal provider service Node1 connector provider
apic1(config-graph)# exit

Step 10

Exit the configuration mode.

Example:

apic1(config-tenant)# exit
apic1(config)# exit

Configuring a Service Graph Template Using the Object Model CLI

You can configure a service graph template using the object model CLI.

The following is an example of a configuration:

admin@apic1:contracts> moconfig running

# contract
cd '/aci/tenants/acme/security-policies/contracts'
mocreate 'webCtrct'
cd 'webCtrct'
moset scope 'tenant'
moconfig commit

# contract-subject
cd '/aci/tenants/acme/security-policies/contracts/webCtrct/subjects'
mocreate 'http'
moconfig commit

# subj-graphatt
cd '/aci/tenants/acme/security-policies/contracts/webCtrct/subjects/http'
mocreate subj-graphatt
cd 'subj-graphatt'
moset name 'WebGraph'
moconfig commit

# vz-rssubjfiltatt
cd '/aci/tenants/acme/security-policies/contracts/webCtrct/subjects/http/common-filters'
mocreate 'wildcard'
moconfig commit

Configuring a Service Graph Template Using the REST APIs

You can configure a service graph template using the following REST API:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<!—L3 Network-->
<fvCtx name="MyNetwork"/>
<!-- Bridge Domain for MySrvr EPG -->
<fvBD name="MySrvrBD">
<fvRsCtx tnFvCtxName="MyNetwork" />
<fvSubnet ip="10.10.10.10/24">
</fvSubnet>
</fvBD>
<!-- Bridge Domain for MyClnt EPG -->
<fvBD name="MyClntBD">
<fvRsCtx tnFvCtxName="MyNetwork" />
<fvSubnet ip="20.20.20.20/24">
</fvSubnet>
</fvBD>
<fvAp dn="uni/tn-acme/ap-MyAP" name="MyAP">
<fvAEPg dn="uni/tn-acme/ap-MyAP/epg-MyClnt" name="MyClnt">
<fvRsBd tnFvBDName="MySrvrBD" />
<fvRsDomAtt tDn="uni/vmmp-Vendor1/dom-MyVMs" />
<fvRsProv tnVzBrCPName="webCtrct">
</fvRsProv>
<fvRsPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/21]" encap="vlan-202"/>
<fvRsPathAtt tDn="topology/pod-1/paths-18/pathep-[eth1/21]" encap="vlan-202"/>
</fvAEPg>
<fvAEPg dn="uni/tn-acme/ap-MyAP/epg-MySRVR" name="MySRVR">
<fvRsBd tnFvBDName="MyClntBD" />
<fvRsDomAtt tDn="uni/vmmp-Vendor1/dom-MyVMs" />
<fvRsCons tnVzBrCPName="webCtrct">
</fvRsCons>
<fvRsPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/21]" encap="vlan-203"/>
<fvRsPathAtt tDn="topology/pod-1/paths-18/pathep-[eth1/21]" encap="vlan-203"/>
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>

- Creating a Security Policy Using the REST APIs

Creating a Security Policy Using the REST APIs

You can create a security policy using the following REST API:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vzFilter name="HttpIn">
<vzEntry name="e1" prot="6" dToPort="80"/>
</vzFilter>
<vzBrCP name="webCtrct">
<vzSubj name="http">
<vzRsSubjFiltAtt tnVzFilterName="HttpIn"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>

Chapter 13. Monitoring a Service Graph

- Monitoring a Service Graph Instance Using the GUI

- Monitoring Service Graph Faults Using the GUI

- Resolving Service Graph Faults

- Monitoring a Virtual Device Using the GUI

- Monitoring Device Cluster and Service Graph Status Using the NX-OS-Style CLI

- Monitoring Device Cluster and Service Graph Status Using the Object Model CLI

Monitoring a Service Graph Instance Using the GUI

After you configure a service graph template and attach the graph to an endpoint group (EPG) and a contract, you can monitor the service graph instance. Monitoring includes viewing the state of the graph instances, functions of a graph instance, resources allocated to a function, and parameters specified for a function.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name for which you want to monitor its service graph.

Step 3

In the Navigation pane, choose tenant_name > L4-L7 Services > Deployed Graph Instancess. The Work pane displays the following information about the active service graph instances:

Name

Description

Service Graph column

The name of the service graph template.

Contract column

The name of the contract that is shown in the service graph template.

Contained By column

The name of the network that contains the service graph template.

State column

The state of the service graph template. A state of applied means that the graph has been applied, and the graph policy is active within the fabric and the service device.

Description column

The description of the service graph.

Step 4

Expand the Deployed Service Graphs branch. The active service graph instances are listed under the branch.

Step 5

Click a service graph instance to view additional information about that instance in the Work pane. The default view is the topology of the graph. You can click one of the tabs in the Work pane to change the view for that graph.

Step 6

Expand the branch for one of the graph instances. The functions of the graph instance are listed under the instance.

Step 7

Click one of the functions to view additional information about that function in the Work pane. The default view is the policy of that function. You can click one of the tabs in the Work pane to change the view for that function. The Work pane displays the following information about the policy:

Name

Description

POLICY tab

The function's properties, resources allocated to the function, and the parameters of the function.

FAULTS tab

The issues that are happening on the function node.

HISTORY tab

The history of events that occurred on the function node.

Step 8

In the Navigation pane, click Deployed Device. The Work pane displays information about the device instances.

Monitoring Service Graph Faults Using the GUI

After you configure a service graph template and attach the graph to an endpoint group (EPG) and a contract, you can monitor a service graph template's faults.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name for which you want to monitor its service graph.

Step 3

In the Navigation pane, expand tenant_name > L4-L7 Services > Deployed Graph Instances.

Step 4

Expand the branch for a graph instance for which you want to view its faults. The functions of the graph instance are listed under the instance.

Step 5

Click on one of the functions. By default, the Work pane shows the policy of that function.

Step 6

Click the FAULTS tab in the Work pane. The Work pane displays the faults of the function node.

Resolving Service Graph Faults

After you have observed one or more service graph template faults, resolving the issue depends on the fault. The following tables describe the faults and provide how to resolve faults.

Connector Faults

Fault

CLI Label

Description and Resolution

missing-connection

connection associated with a connector not found

The configuration for a graph connector is invalid. The associated connection for the connector could not be found.

missing-nodeinst

NodeInst associated with a connector not found

The configuration for a graph connector is invalid. The associated NodeInst for the connector could not be found.

conn-nonrenderable

Graph connector could not be rendered.

The configuration for a graph connector is invalid. The graph could not be rendered.

invalid-bd

BD associated with a connector is not valid

The configuration for a graph connector is invalid. The associated bridge domain for the connector is not valid.

invalid-ctx

Ctx associated with a connector is not valid.

The configuration for a graph connector is invalid. The associated Ctx for the connector is not valid.

missing-peer-conn

Peer connector associated with a connector not found.

Configuration for a graph connector is invalid. The peer connector for the connection could not be found.

AbsGraph and GraphInst Faults

Fault

CLI Label

Description and Resolution

invalid-abstract-graph-config

invalid abstract graph config

The abstract graph configuration is invalid.

missing-mandatory-param

mandatory param not found

A mandatory configuration parameter could not be resolved. Check the package for the mandatory parameter and make sure that AbsGraph has the parameter.

param-cardinality-error

invalid param cardinality

A configuration parameter does not meet cardinality requirements. Check if you specified multiple instances of a parameter without specifying cardinality=n.

epp-download-failure

epp download failure

Graph policies failed to download to the switch.

param-duplicate-name-failure

duplicate param name

Multiple identical copies of a parameter were found with the same name.

id-allocation-failure

id allocation failure

A unique network resource (either VLAN or VXLAN) could not be allocated.

missing-ldev

No cluster found

A cluster could not be found.

context-cardinality-violation-failure

invalid cluster context cardinality

The cluster does not support the required tenancy(multi-tenant or single tenant).

function-type-mismatch-failure

invalid function type

The function type is not supported for the selected device. Check if the AbsNode functype and resolved LDevVip function type match.

invalid-abstract-graph-config-param

invalid abstract graph config param

The abstract graph configuration parameter is invalid.

missing-mparam

No parameter definition found

A required parameter definition could not be found.

missing-abs-graph

no abs graph found

The abstract graph configuration is missing for the graph instance.

invalid-param-config

invalid param config

The parameter configuration is invalid.

invalid-param-scope

invalid parameter scope

The parameter scope is invalid. Check the vnsRsScopeToTerm parameter in the AbsGraph to see if parameter is correct.

invalid-ldev

Invalid cluster

The cluster configuration is invalid. Check the status of the resolved LDevVip and correct the fault.

missing-tenant

no tenant found

The tenant could not be found for the graph.

internal-error

internal error

An internal error occurred during graph processing.

resource-allocation-failure

resource allocation failure

A required resource could not be allocated during graph processing.

missing-abs-function

no abstract function found

The abstract function definition is missing.

param-validation-failed

param validation failure

The configuration parameter value is invalid.

missing-mconn

No connector found

A required connector could not be found.

cdev-missing-mgmt-ip

no mgmt ip found for cdev

The management IP address could not be found for concrete device. Check if vnsCMgmt is present for the resolved vnsCDev.

invalid-graphinst

invalid graphinst config

The graph instance is invalid.

missing-interface

no interface found

An interface could not be found.

missing-bd

no bd found

A bridge domain could not be found.

missing-terminal

Terminal node is missing a terminal

Terminal node is missing a terminal. Check the terminal node settings.

missing-namespace

no vlan/vxlan namespace found

The namespace that is needed to allocate the VLAN or VXLAN is missing. Verify that the resolved vnsLDevVip has the phyDomp parameter or the vmmDomp parameter configured that has a relation to the resolved fvnsVlanInstp.

missing-mfunc

No function found in device package

A required function could not be found in the device package. Verify that all AbsNode function types are present in the package.

missing-lif

no cluster interface found

A required cluster interface could not be found. Verify that the vnsLIf parameter in vnsLDevVip is configured correctly.

invalid-absfunc-profile

Abstract Function Profile config is invalid

The abstract function profile configuration is invalid. This fault may be due to an invalid configuration parameter that is specified in the profile.

missing-cdev

No device found

The concrete device could not be found in the cluster. Verify that a valid vnsCDev is present under the resolved vnsLDevVip.

inappropriate-devfolder

Illegal folder in configuration

No corresponding folder was found in the device package.

invalid-devctx

Device context is not legal for this folder

The device package does not allow specifying a device context for this folder.

insufficient-devctx

Folder must have one value for each associated CDev

The folder is concrete device specific. The folder must have at least one value for each concrete device.

cdev-missing-cif

No interface defined

A concrete device must have at least one interface defined.

cdev-missing-pathinfo

Missing path for interface

For a physical service appliance, we must know to which leaf ports the interface is connected. Verify that the vnsCifPathAtt parameter is present for all vnsCIf under the resolved vnsCDev.

missing-cif

Device interfaces does not match cluster

The device interfaces should match the interfaces configured for their cluster. Verify that the vnsCIf parameter and the vnsLIf parameter are present under the resolved vnsLDevVip.

ldevvip-missing-mgmt-ip

No Mgmt ip found for LDevVip

The management IP address could not be found for LDevVip.

lif-invalid-MIf

LIf has an invalid MifLbl

The MIfLbl contained by LIf is not present in the device package.

lif-invalid-CIf

LIf has an invalid CIf

The CIf contained by LIf is not present. Check the concrete device and CIf settings.

missing-function-node

Abstract graph missing function node

An abstract graph must have at least one function node.

graph-loop-detected

Abstract graph config has a loop

The abstract graph configuration is invalid. The configuration has a loop.

gothrough-routing-enabled-both

Both the legs of go through node has routing enabled

Both the legs of the go through node have routing enabled.

invalid-terminal-nodes

Abstract graph has invalid number of terminal nodes

An abstract graph must have at least two terminal nodes.

missing-ldev-ctx

No device context found for LDev

The device context for the device could not be found. Verify that vnsLDevCtx has values that match the contract, graph and node.

arp-flood-enabled

ARP flood is enabled on the management end point group

ARP flood must be disabled for the management endpoint group.

folderinst-validation-failed

FolderInst has key, that is not found in MFolder

The FolderInst's key and value should honor MFolder specifications.

paraminst-validation-failed

ParamInst has key and/or value, that are not found in MParam

ParamInst's key and value should honor MParam specifications.

invalid-mfolder

FolderInst points to an invalid MFolder

FolderInst must point to a valid MFolder.

invalid-mparam

ParamInst points to an invalid MParam

ParamInst must point to a valid MParam.

devfolder-validation-failed

DevFolder has key, that is not found in MFolder

DevFolders key and value should honor MFolder specifications.

devparam-validation-failed

DevParam has key and/or value, that are not found in MParam

DevParam's key and value should honor MParam specifications

cdev-missing-virtual-info

Virtual Object Info is missing in CDev

Virtual object information must be provided if LDevVip is of type Virtual.

invalid-rsmconnatt

Relationship to metaconnector is invalid

Correct the metaconnector DN and ensure it binds to the correct MDev hierarchy.

Monitoring a Virtual Device Using the GUI

After you configure a service graph template and attach the graph to an endpoint group (EPG) and a contract, you can monitor the virtual devices of a tenant. Monitoring the virtual devices tells you what devices are in use, which VLANs are configured for a device, the parameters passed to the devices, the statistics of the devices, and the health of the devices.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name for which you want to monitor its service graph.

Step 3

In the Navigation pane, expand tenant_name > L4-L7 Services > Deployed Devices.

Step 4

Click on one of the deployed devices. By default, the Work pane shows the policy of that deployed device. You can click the tabs in the Work pane to change the view. The tabs display the following information about the virtual device:

Tab

Description

POLICY tab

The device that is in use, the VLANs that are configured within the device, and the parameters that have been passed to the devices.

OPERATIONAL tab

The statistics that are being received from the various devices.

HEALTH tab

The health of the devices.

Monitoring Device Cluster and Service Graph Status Using the NX-OS-Style CLI

The commands in this section provide examples of how to monitor device cluster and service graph status using the NX-OS-style CLI.

Showing the Operation Information of a Device Cluster

The following command shows the operational information of a device cluster:

show l4l7-cluster tenant tenant_name cluster device_cluster_name

Example:

apic1# show l4l7-cluster tenant HA_Tenant1 cluster Firewall
tenant-graph : HA_Tenant1-g2,HA_Tenant1-g1

Device Cluster    : Firewall
Cluster Interface : consumer1
Encap             : vlan-501
Pctag             : 32773
Devices           : FW2(int),FW1(int)
Graphs            : HA_Tenant1-g1
Contracts         : HA_Tenant1-c1

Device Cluster    : Firewall
Cluster Interface : provider1
Encap             : vlan-502
Pctag             : 32774
Devices           : FW2(ext),FW1(ext)
Graphs            : HA_Tenant1-g1
Contracts         : HA_Tenant1-c1

Showing the Operation Status of a Device Cluster

The following command shows the operation status of a device cluster:

apic1# show l4l7-graph tenant tenant_name [graph graph_name]

Examples:

The following example gives high-level output of the status of the HA_Tenant1 tenant:

apic1# show l4l7-graph tenant HA_Tenant1
Graph           : g1
Total Instances : 1
Encaps Used     : vlan-501,vlan-502,vlan-503,vlan-504
Device Used     : uni/tn-HA_Tenant1/lDevVip-Firewall

Graph           : g2
Total Instances : 1
Encaps Used     : vlan-501,vlan-502,vlan-503,vlan-504
Device Used     : uni/tn-HA_Tenant1/lDevVip-Firewall

The following example gives detailed output of the status of the g1 service graph that is associated with the HA_Tenant1 tenant:

apic1# show l4l7-graph tenant HA_Tenant1 graph g1
Graph           : HA_Tenant1-g1
Graph Instances : 1

Consumer EPg  : HA_Tenant1-consEPG1
Provider EPg  : HA_Tenant1-provEPG1
Contract Name : HA_Tenant1-c1
Config status : applied

Function Node Name : Node1
Connector   Encap       Bridge-Domain  Device Interface
----------  ----------  ----------     ---------------------
consumer    vlan-3001   provBD1        consumer
provider    vlan-3335   consBD1        provider

Showing the Faults of a Device Cluster

The following command shows the faults of a device cluster:

show faults l4l7-cluster

Example:

apic1# show faults l4l7-cluster
Code            : F0772
Severity        : minor
Last Transition : 2015-09-01T01:41:13.767+00:00
Lifecycle       : soaking-clearing
Affected object : uni/tn-ts1/lDevVip-d1/lIf-ext/fault-F0772
Description     : LIf configuration ext for L4-L7 Devices d1 for tenant ts1
is invalid.

Code            : F1085
Severity        : cleared
Last Transition : 2015-09-01T01:39:04.696+00:00
Lifecycle       : retaining
Affected object : uni/tn-ts1/lDevVip-d1/rsmDevAtt/fault-F1085
Description     : Failed to form relation to MO uni/infra/mDev-CiscoInternal-
NetworkOnly-1.0 of class vnsMDev

Code            : F1690
Severity        : minor
Last Transition : 2015-09-01T01:39:04.676+00:00
Lifecycle       : soaking
Affected object : uni/tn-ts1/lDevVip-d1/vnsConfIssue-missing-
namespace/fault-F1690
Description     : Configuration is invalid due to no vlan/vxlan namespace
found

Showing the Faults of a Service Graph

The following command shows the faults of a service graph:

show faults l4l7-graph

Example:

apic1# show faults l4l7-graph
Code            : F1690
Severity        : minor
Last Transition : 2015-11-25T20:07:33.635+00:00
Lifecycle       : raised
DN              : uni/tn-HA_Tenant1/AbsGraph-WebGraph/vnsConfIssue-invalid-
abstract-graph-config-param/fault-F1690
Description     : Configuration is invalid due to invalid abstract graph
config param

Showing the Running Configuration of a Device Cluster

The following command shows the running configuration of a device cluster:

show running-config tenant tenant_name l4l7 cluster

Example:

apic1# show running-config tenant common l4l7 cluster
# Command: show running-config tenant common l4l7 cluster
# Time: Thu Nov 26 00:35:59 2015
tenant common
l4l7 cluster name ifav108-asa type physical vlan-domain phyDom5 service FW function go-through
cluster-device C1
cluster-interface consumer_1
member device C1 device-interface port-channel1
interface vpc VPCPolASA leaf 103 104
exit
exit
cluster-interface provider_1
member device C1 device-interface port-channel1
interface vpc VPCPolASA leaf 103 104
exit
exit
exit

Showing the Running Configuration of a Service Graph

The following command shows the running configuration of a service graph:

show running-config tenant tenant_name l4l7 graph

Example:

apic1# show running-config tenant common l4l7 graph
# Command: show running-config tenant common l4l7 graph
# Time: Thu Nov 26 00:35:59 2015
tenant T1
l4l7 graph Graph-Citrix contract Contract-Citrix
service N1 device-cluster-tenant common device-cluster ifav108-citrix mode ADC_ONE_ARM
connector provider cluster-interface pro
bridge-domain tenant common name BD4-Common
exit
connector consumer cluster-interface pro
bridge-domain tenant common name BD4-Common
exit
exit
connection C1 terminal consumer service N1 connector consumer
connection C2 terminal provider service N1 connector provider
exit

Monitoring Device Cluster and Service Graph Status Using the Object Model CLI

The commands in this section provide examples of how to monitor device cluster and service graph status using the object model CLI.

Showing the Status of All Device Clusters

The following command shows the status of all device clusters:

apic1# show l4l7-cluster
Device Cluster        : InsiemeCluster
Total Graph Instances : 2
Active Graphs         : G2,G1
Encaps Used           : vlan-202,vlan-268

Showing the Status of All Device Clusters in a Specified Tenant

The following command shows the status of all device clusters in tenant tnt1:

apic1# show l4l7-cluster tenant tnt1
Device Cluster        : InsiemeCluster
Total Graph Instances : 2
Active Graphs         : G2,G1
Encaps Used           : vlan-202,vlan-268

Showing the Status of a Specified Device Cluster in a Specified Tenant

The following command shows the status of device cluster InsiemeCluster in tenant tnt1:

apic1# show l4l7-cluster tenant tnt1 cluster InsiemeCluster
tenant-graph : G1,G2

Device Cluster    : InsiemeCluster
Cluster Interface : outside
Encap             : vlan-202
Pctag             : 49155
Devices           : Generic1(int),Generic2(int)
Graphs            : G1,G2
Contracts         : webCtrct

Device Cluster    : InsiemeCluster
Cluster Interface : inside
Encap             : vlan-237
Pctag             : 32772
Devices           : Generic2(ext),Generic1(ext)
Graphs            : G1,G2
Contracts         : webCtrct

Showing the Status of All Service Graphs

The following command shows the status of all service graphs:

apic1# show l4l7-graph
Graph           : G2
Total Instances : 1
Encaps Used     : vlan-202,vlan-268
Device Used     : uni/tn-tnt1/lDevVip-InsiemeCluster

Graph           : G1
Total Instances : 1
Encaps Used     : vlan-202,vlan-268
Device Used     : uni/tn-tnt1/lDevVip-InsiemeCluster

Showing the Status of a Specified Service Graph

The following command shows the status of service graph G1:

apic1# show l4l7-graph graph G1
Graph           : G1
Total Instances : 1

Consumer EPg  : uni/tn-tnt1/ap-sap/epg-app
Provider EPg  : uni/tn-tnt1/ap-sap/epg-web
Contract Name : uni/tn-tnt1/brc-webCtrct

Function Connector : outside
Encap              : vlan-202
BD                 : tnt1BD2
Device             : uni/tn-tnt1/lDevVip-InsiemeCluster

Function Connector : inside
Encap              : vlan-268
BD                 : tnt1BD1
Device             : uni/tn-tnt1/lDevVip-InsiemeCluster

Showing the Status of All Service Graphs of a Specified Tenant

The following command shows the status of all service graph of tenant tnt1:

apic1# show l4l7-graph tenant tnt1
Graph           : G2
Total Instances : 1
Encaps Used     : vlan-202,vlan-268
Device Used     : uni/tn-tnt1/lDevVip-InsiemeCluster

Graph           : G1
Total Instances : 1
Encaps Used     : vlan-202,vlan-268
Device Used     : uni/tn-tnt1/lDevVip-InsiemeCluster

Showing the Status of a Specified Service Graph of a Specified Tenant

The following command shows the status of service graph G2 of tenant tnt1:

apic1# show l4l7-graph tenant tnt1 graph G2
Graph           : G2
Total Instances : 1

Consumer EPg  : uni/tn-tnt1/ap-sap/epg-app
Provider EPg  : uni/tn-tnt1/ap-sap/epg-web
Contract Name : uni/tn-tnt1/brc-webCtrct

Function Connector : outside
Encap              : vlan-202
BD                 : tnt1BD2
Device             : uni/tn-tnt1/lDevVip-InsiemeCluster

Function Connector : inside
Encap              : vlan-268
BD                 : tnt1BD1
Device             : uni/tn-tnt1/lDevVip-InsiemeCluster

Chapter 14. Configuring Administrator Roles for Managing a Service Configuration

- About Privileges

- Configuring a Role for Device Management

- Configuring a Role for Service Graph Template Management

- Configuring a Role for Uploading Device Package

- Configuring a Role for Exporting Devices

About Privileges

You can grant privileges to the roles that you configure in the Application Policy Infrastructure Controller (APIC). Privileges determine what tasks a role is allowed to perform. You can grant the following privileges to the administrator roles:

Privilege

Description

nw-svc-policy

The network service policy privilege enables you to do the following:

- Create a service graph template

- Attach a service graph template to an application endpoint group (EPG) and a contract

- Monitor a service graph

nw-svc-device

The network service device privilege enables you to do the following:

- Create a device

- Create a concrete device

- Create a device context

Note

Only the infrastructure administrator can upload a device package to the APIC.

Configuring a Role for Device Management

To enable a role to manage devices, you must grant the following privilege to that role:

- nw-svc-device

Configuring a Role for Service Graph Template Management

To enable a role to manage service graph templatess, you must grant the following privilege to that role:

- nw-svc-policy

Configuring a Role for Uploading Device Package

A device package can be uploaded only with the APIC infra admin privilege. Infra admin uploads the device packages. All other tenant administrators have read-only access to the device package. Tenant administrators can access and use various functions available from the device package.

Configuring a Role for Exporting Devices

Devices can be exported to enable sharing of devices among tenants. A tenant with the role nw-device can create a device. If the tenant that owns the device wants to share these with another tenant, the sharing requires the nw-svc-devshare privilege.

The nw-svc-devshare privilege allows a tenant to be able to export devices.

Note

To be able to use imported devices, other tenants that have imported devices need to have the nw-svc-policy privilege.

Chapter 15. Developing Automation

- About the REST APIs

- Examples of Automating Using the REST APIs

About the REST APIs

Automation relies on the Application Policy Infrastructure Controller (APIC) northbound Representational State Transfer (REST) APIs. Anything that can be done through the APIC UI can also be done using XML-based REST POSTs using the northbound APIs. For example, you can monitor events through those APIs, dynamically enable EPGs, and add policies.

You can also use the northbound REST APIS to monitor for notifications that a device has been brought onboard, and to monitor faults. In both cases, you can use the monitoring as events that trigger specific actions. For example, if you see faults that occur on a specific application tier and determine that there is a loss of connectivity and a leaf node is going down, you can trigger an action to redeploy those applications somewhere else. If you have certain contracts on which you detect packet drops occurring, you could enable some copies of those contracts on the particular application. You can also use a statistics monitoring policy, where you monitor certain counters because of issues that have been reported.

The Cisco APIC REST API User Guide contains a list of the northbound REST APIs, along with information on how you can use the APIs. You can write your own orchestration tools using these APIs to configure your services on the APIC.

For information on how to construct the XML files submitted to the APIC northbound API, see Cisco APIC Layer 4 to Layer 7 Device Package Development Guide .

The following Python APIs, defined in the Cisco APIC Management Information Model Reference, can be used to submit REST POST calls using the northbound API:

- vns:LDevVip: Upload a device cluster

- vns:CDev: Upload a device

- vns:LIf: Create logical interfaces

- vns:AbsGraph: Create a graph

- vz:BrCP: Attach a graph to a contract

For information on how to construct POSTs using the northbound REST API, including information how to do so in Python, see the Cisco APIC REST API User Guide.

Examples of Automating Using the REST APIs

This section contains examples of using the REST APIs to automate tasks.

The following REST request creates a tenant with a broadcast domain, a Layer 3 network, application endpoint groups, and an application profile:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">

<!—L3 Network-->
<fvCtx name="MyNetwork"/>

<!-- Bridge Domain for MySrvr EPG -->
<fvBD name="MySrvrBD">
<fvRsCtx tnFvCtxName="MyNetwork"/>
<fvSubnet ip="10.10.10.10/24">
</fvSubnet>
</fvBD>

<!-- Bridge Domain for MyClnt EPG -->
<fvBD name="MyClntBD">
<fvRsCtx tnFvCtxName="MyNetwork"/>
<fvSubnet ip="20.20.20.20/24">
</fvSubnet>
</fvBD>

<fvAp dn="uni/tn-acme/ap-MyAP" name="MyAP">

<fvAEPg dn="uni/tn-acme/ap-MyAP/epg-MyClnt" name="MyClnt">
<fvRsBd tnFvBDName="MySrvrBD"/>
<fvRsDomAtt tDn="uni/vmmp-Vendor1/dom-MyVMs"/>
<fvRsProv tnVzBrCPName="webCtrct"> </fvRsProv>
<fvRsPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/21]"
encap="vlan-202"/>
<fvRsPathAtt tDn="topology/pod-1/paths-18/pathep-[eth1/21]"
encap="vlan-202"/>
</fvAEPg>

<fvAEPg dn="uni/tn-acme/ap-MyAP/epg-MySRVR" name="MySRVR">
<fvRsBd tnFvBDName="MyClntBD"/>
<fvRsDomAtt tDn="uni/vmmp-Vendor1/dom-MyVMs"/>
<fvRsCons tnVzBrCPName="webCtrct"> </fvRsCons>
<fvRsPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/21]"
encap="vlan-203"/>
<fvRsPathAtt tDn="topology/pod-1/paths-18/pathep-[eth1/21]"
encap="vlan-203"/>
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>

The following REST request creates a VLAN namespace:

<polUni>
<infraInfra>
<fvnsVlanInstP name="MyNS" allocMode="dynamic">
<fvnsEncapBlk name="encap" from="vlan-201" to="vlan-300"/>
</fvnsVlanInstP>
</infraInfra>
</polUni>

The following REST request creates a VMM domain:

<polUni>
<vmmProvP vendor="Vendor1">
<vmmDomP name="MyVMs">
<infraRsVlanNs tDn="uni/infra/vlanns-MyNS-dynamic"/>
<vmmUsrAccP name="admin" usr="administrator" pwd="in$1eme"/>
<vmmCtrlrP name="vcenter1" hostOrIp="192.168.64.186">
<vmmRsAcc tDn="uni/vmmp-Vendor1/dom-MyVMs/usracc-admin"/>
</vmmCtrlrP>
</vmmDomP>
</vmmProvP>
</polUni>

The following REST request creates a physical domain:

<polUni>
<physDomP name="phys">
<infraRsVlanNs tDn="uni/infra/vlanns-MyNS-dynamic"/>
</physDomP>
</polUni>

The following REST request creates a managed device cluster:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vnsLDevVip name="ADCCluster1" contextAware=1>
<vnsRsMDevAtt tDn="uni/infra/mDev-Acme-ADC-1.0"/>
<vnsRsDevEpg tDn="uni/tn-acme/ap-services/epg-ifc"/>
<vnsRsALDevToPhysDomP tDn="uni/phys-phys"/>

<vnsCMgmt name="devMgmt" host="42.42.42.100" port="80"/>

<vnsCCred name="username"value="admin"/>

<vnsCCredSecret name="password" value="admin"/>
</vnsLDevVip>
</fvTenant>
</polUni>

The following REST request creates an unmanaged device cluster:

<polUni>
<fvTenant name="HA_Tenant1">

<vnsLDevVip name="ADCCluster1" devtype="VIRTUAL" managed="no">
<vnsRsALDevToDomP tDn="uni/vmmp-VMware/dom-mininet"/>
</vnsLDevVip>

</fvTenant>
</polUni>

The following REST request creates a device cluster context:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vnsLDevCtx ctrctNameOrLbl="webCtrct" graphNameOrLbl="G1" nodeNameOrLbl="Node1">
<vnsRsLDevCtxToLDev tDn="uni/tn-acme/lDevVip-ADCCluster1"/>
<vnsLIfCtx connNameOrLbl="ssl-inside">
<vnsRsLIfCtxToLIf tDn="uni/tn-acme/lDevVip-ADCCluster1/lIf-int"/>
</vnsLIfCtx>
<vnsLIfCtx connNameOrLbl="any">
<vnsRsLIfCtxToLIf tDn="uni/tn-acme/lDevVip-ADCCluster1/lIf-ext"/>
</vnsLIfCtx>
</vnsLDevCtx>
</fvTenant>
</polUni>

The following REST request creates a device cluster context used in route peering:

<polUni>
<fvTenant dn="uni/tn-coke{{tenantId}}" name="coke{{tenantId}}">
<vnsRtrCfg name="Dev1Ctx1" rtrId="180.0.0.12"/>
<vnsLDevCtx ctrctNameOrLbl="webCtrct1" graphNameOrLbl="WebGraph"
nodeNameOrLbl="FW">
<vnsRsLDevCtxToLDev tDn="uni/tn-tenant1/lDevVip-Firewall"/>
<vnsRsLDevCtxToRtrCfg tnVnsRtrCfgName="FwRtrCfg"/>
<vnsLIfCtx connNameOrLbl="internal">
<vnsRsLIfCtxToInstP tDn="uni/tn-tenant1/out-OspfInternal/instP-IntInstP"
status="created,modified"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-tenant1/lDevVip-Firewall/lIf-internal"/>
</vnsLIfCtx>
<vnsLIfCtx connNameOrLbl="external">
<vnsRsLIfCtxToInstP tDn="uni/tn-common/out-OspfExternal/instP-ExtInstP"
status="created,modified"/>
<vnsRsLIfCtxToLIf tDn="uni/tn-tenant1/lDevVip-Firewall/lIf-external"/>
</vnsLIfCtx>
</vnsLDevCtx>
</fvTenant>
</polUni>

Note

For information about configuring external connectivity for tenants (a Layer 3 outside), see the Cisco APIC Getting Started Guide.

The following REST request adds a logical interface in a device cluster:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vnsLDevVip name="ADCCluster1">
<vnsLIf name="C5">
<vnsRsMetaIf tDn="uni/infra/mDev-Acme-ADC-1.0/mIfLbl-outside"/>
<vnsRsCIfAtt tDn="uni/tn-acme/lDevVip-ADCCluster1/cDev-ADC1/cIf-int"/>
</vnsLIf>
<vnsLIf name="C4">
<vnsRsMetaIf tDn="uni/infra/mDev-Acme-ADC-1.0/mIfLbl-inside"/>
<vnsRsCIfAtt tDn="uni/tn-acme/lDevVip-ADCCluster1/cDev-ADC1/cIf-ext"/>
</vnsLIf>
</vnsLDevVip>
</fvTenant>
</polUni>

The following REST request adds a concrete device in a physical device cluster:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vnsLDevVip name="ADCCluster1">
<vnsCDev name="ADC1" devCtxLbl="C1">
<vnsCIf name="int">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/22]"/>
</vnsCIf>
<vnsCIf name="ext">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/21]"/>
</vnsCIf>
<vnsCIf name="mgmt">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/20]"/>
</vnsCIf>
<vnsCMgmt name="devMgmt" host="172.30.30.100" port="80"/>
<vnsCCred name="username" value="admin"/>
<vnsCCred name="password" value="admin"/>
</vnsCDev>
<vnsCDev name="ADC2" devCtxLbl="C2">
<vnsCIf name="int">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/23]"/>
</vnsCIf>
<vnsCIf name="ext">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/24]"/>
</vnsCIf>
<vnsCIf name="mgmt">
<vnsRsCIfPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/30]"/>
</vnsCIf>
<vnsCMgmt name="devMgmt" host="172.30.30.200" port="80"/>
<vnsCCred name="username" value="admin"/>
<vnsCCred name="password" value="admin"/>
</vnsCDev>
</vnsLDevVip>
</fvTenant>
</polUni>

The following REST request adds a concrete device in a virtual device cluster:

<polUni>
<fvTenant dn="uni/tn-coke5" name="coke5">
<vnsLDevVip name="Firewall5" devtype="VIRTUAL">
<vnsCDev name="ASA5" vcenterName="vcenter1" vmName="ifav16-ASAv-scale-05">
<vnsCIf name="Gig0/0" vnicName="Network adapter 2"/>
<vnsCIf name="Gig0/1" vnicName="Network adapter 3"/>
<vnsCIf name="Gig0/2" vnicName="Network adapter 4"/>
<vnsCIf name="Gig0/3" vnicName="Network adapter 5"/>
<vnsCIf name="Gig0/4" vnicName="Network adapter 6"/>
<vnsCIf name="Gig0/5" vnicName="Network adapter 7"/>
<vnsCIf name="Gig0/6" vnicName="Network adapter 8"/>
<vnsCIf name="Gig0/7" vnicName="Network adapter 9"/>
<vnsCMgmt name="devMgmt" host="3.5.3.170" port="443"/>
<vnsCCred name="username" value="admin"/>
<vnsCCredSecret name="password" value="insieme"/>
</vnsCDev>
</vnsLDevVip>
</fvTenant>
</polUni>

The following REST request creates a service graph in managed mode:

<polUni>
<fvTenant name="acme">
<vnsAbsGraph name = "G1">

<vnsAbsTermNode name = "Input1">
<vnsAbsTermConn name = "C1" direction = "output">
</vnsAbsTermConn>
</vnsAbsTermNode>

<!-- Node1 Provides SLB functionality -->
<vnsAbsNode name = "Node1" funcType="GoTo" >
<vnsRsDefaultScopeToTerm
tDn="uni/tn-acme/AbsGraph-G1/AbsTermNode-Output1/outtmnl"/>

<vnsAbsFuncConn name = "C4" direction = "input">
<vnsRsMConnAtt tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB/mConn-external"/>
<vnsRsConnToLIf tDn="uni/tn-acme/lDevVip-ADCCluster1/lIf-C4"/>
</vnsAbsFuncConn>

<vnsAbsFuncConn name = "C5" direction = "output">
<vnsRsMConnAtt tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB/mConn-internal"/>
<vnsRsConnToLIf tDn="uni/tn-acme/lDevVip-ADCCluster1/lIf-C5"/>
</vnsAbsFuncConn>

<vnsRsNodeToMFunc tDn="uni/infra/mDev-Acme-ADC-1.0/mFunc-SLB"/>
</vnsAbsNode>

<vnsAbsTermNode name = "Output1">
<vnsAbsTermConn name = "C6" direction = "input">
</vnsAbsTermConn>
</vnsAbsTermNode>

<vnsAbsConnection name = "CON1">
<vnsRsAbsConnectionConns
tDn="uni/tn-acme/AbsGraph-G1/AbsTermNode-Input1/AbsTConn"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-acme/AbsGraph-G1/AbsNode-Node1/AbsFConn-C4"/>
</vnsAbsConnection>

<vnsAbsConnection name = "CON3">
<vnsRsAbsConnectionConns
tDn="uni/tn-acme/AbsGraph-G1/AbsNode-Node1/AbsFConn-C5"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-acme/AbsGraph-G1/AbsTermNode-Output1/AbsTConn"/>
</vnsAbsConnection>
</vnsAbsGraph>
</fvTenant>
</polUni>

The following REST request creates a service graph in unmanaged mode:

<polUni>
<fvTenant name="HA_Tenant1">
<vnsAbsGraph name="g1">

<vnsAbsTermNodeProv name="Input1">
<vnsAbsTermConn name="C1">
</vnsAbsTermConn>
</vnsAbsTermNodeProv>

<!-- Node1 Provides LoadBalancing functionality -->
<vnsAbsNode name="Node1" managed="no">
<vnsRsDefaultScopeToTerm
tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsTermNodeProv-Input1/outtmnl"/>
<vnsAbsFuncConn name="outside" attNotify="true">
</vnsAbsFuncConn>
<vnsAbsFuncConn name="inside" attNotify="true">
</vnsAbsFuncConn>
</vnsAbsNode>

<vnsAbsTermNodeCon name="Output1">
<vnsAbsTermConn name="C6">
</vnsAbsTermConn>
</vnsAbsTermNodeCon>

<vnsAbsConnection name="CON2" adjType="L3" unicastRoute="yes">
<vnsRsAbsConnectionConns
tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsTermNodeCon-Output1/AbsTConn"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsNode-Node1/AbsFConn-outside"/>
</vnsAbsConnection>

<vnsAbsConnection name="CON1" adjType="L2" unicastRoute="no">
<vnsRsAbsConnectionConns
tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsNode-Node1/AbsFConn-inside"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-HA_Tenant1/AbsGraph-g1/AbsTermNodeProv-Input1/AbsTConn"/>
</vnsAbsConnection>

</vnsAbsGraph>
</fvTenant>
</polUni>

The following REST request creates a security policy (contract):

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">
<vzFilter name="HttpIn">
<vzEntry name="e1" prot="6" dToPort="80"/>
</vzFilter>

<vzBrCP name="webCtrct">
<vzSubj name="http">
<vzRsSubjFiltAtt tnVzFilterName="HttpIn"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>

The following REST request provides graph configuration parameters from an application EPG:

<polUni>
<fvTenant dn="uni/tn-acme" name="acme">

<!-- Application Profile -->
<fvAp dn="uni/tn-acme/ap-MyAP" name="MyAP">

<!-- EPG 1  -->
<fvAEPg dn="uni/tn-acme/ap-MyAP/epg-MyClnt" name="MyClnt">
<fvRsBd tnFvBDName="MyClntBD"/>
<fvRsDomAtt tDn="uni/vmmp-Vendor1/dom-MyVMs"/>
<fvRsProv tnVzBrCPName="webCtrct">
</fvRsProv>
<fvRsPathAtt tDn="topology/pod-1/paths-17/pathep-[eth1/20]" encap="vlan-201"/>
<fvSubnet name="SrcSubnet" ip="192.168.10.1/24"/>
</fvAEPg>

<!-- EPG 2 -->
<fvAEPg dn="uni/tn-acme/ap-MyAP/epg-MySRVR"  name="MySRVR">
<fvRsBd tnFvBDName="MyClntBD"/>
<fvRsDomAtt tDn="uni/vmmp-Vendor1/dom-MyVMs"/>
<fvRsCons tnVzBrCPName="webCtrct">
</fvRsCons>

<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any"
key="Monitor" name="monitor1">
<vnsParamInst name="weight" key="weight" value="10"/>
</vnsFolderInst>

<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any" nodeNameOrLbl="any"
key="Service" name="Service1">
<vnsParamInst name="servicename" key="servicename"
value="crpvgrtst02-8010"/>
<vnsParamInst name="servicetype" key="servicetype" value="TCP"/>
<vnsParamInst name="servername" key="servername"
value="s192.168.100.100"/>
<vnsParamInst name="serveripaddress" key="serveripaddress"
value="192.168.100.100"/>
<vnsParamInst name="serviceport" key="serviceport" value="8080"/>
<vnsParamInst name="svrtimeout" key="svrtimeout" value="9000"/>
<vnsParamInst name="clttimeout" key="clttimeout" value="9000"/>
<vnsParamInst name="usip" key="usip" value="NO"/>
<vnsParamInst name="useproxyport" key="useproxyport" value=""/>
<vnsParamInst name="cip" key="cip" value="ENABLED"/>
<vnsParamInst name="cka" key="cka" value="NO"/>
<vnsParamInst name="sp" key="sp" value="OFF"/>
<vnsParamInst name="cmp" key="cmp" value="NO"/>
<vnsParamInst name="maxclient" key="maxclient" value="0"/>
<vnsParamInst name="maxreq" key="maxreq" value="0"/>
<vnsParamInst name="tcpb" key="tcpb" value="NO"/>
<vnsCfgRelInst name="MonitorConfig" key="MonitorConfig"
targetName="monitor1"/>
</vnsFolderInst>

<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" key="Network" name="Network">
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" key="vip" name="vip">
<vnsParamInst name="vipaddress1" key="vipaddress"
value="10.10.10.100"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" devCtxLbl="C1" key="snip" name="snip1">
<vnsParamInst name="snipaddress" key="snipaddress"
value="192.168.1.100"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" devCtxLbl="C2" key="snip" name="snip2">
<vnsParamInst name="snipaddress" key="snipaddress"
value="192.168.1.101"/>
</vnsFolderInst>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" devCtxLbl="C3" key="snip" name="snip3">
<vnsParamInst name="snipaddress" key="snipaddress"
value="192.168.1.102"/>
</vnsFolderInst>
</vnsFolderInst>

<!-- SLB Configuration -->
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" key="VServer" name="VServer">
<!-- Virtual Server Configuration -->
<vnsParamInst name="port" key="port" value="8010"/>
<vnsParamInst name="vip" key="vip" value="10.10.10.100"/>
<vnsParamInst name="vservername" key="vservername"
value="crpvgrtst02-vip-8010"/>
<vnsParamInst name="servicename" key="servicename"
value="crpvgrtst02-8010"/>
<vnsParamInst name="servicetype" key="servicetype" value="TCP"/>
<vnsFolderInst ctrctNameOrLbl="any" graphNameOrLbl="any"
nodeNameOrLbl="any" key="VServerGlobalConfig" name="VServerGlobalConfig">
<vnsCfgRelInst name="ServiceConfig" key="ServiceConfig"
targetName="Service1"/>
<vnsCfgRelInst name="VipConfig" key="VipConfig"
targetName="Network/vip"/>
</vnsFolderInst>
</vnsFolderInst>
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>

The following REST request attaches a service graph to a contract:

<polUni>
<fvTenant name="acme">
<vzBrCP name="webCtrct">
<vzSubj name="http">
<vzRsSubjGraphAtt graphName="G1" termNodeName="Input1"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>

Chapter 16. Using the GUI

- Deploying the Layer 4 to Layer 7 Services Using the GUI

- Importing a Device Package Using the GUI

- Creating a Function Profile Using the GUI

- Creating a Layer 4 to Layer 7 Service Graph Template Using the GUI

- Modifying a Device

- Applying a Service Graph Template to Endpoint Groups Using the GUI

Deploying the Layer 4 to Layer 7 Services Using the GUI

You can deploy the Layer 4 to Layer 7 services using GUI. Perform the procedures in the following order:

1. Import a device package.

See Importing a Device Package Using the GUI.

2. Create a function profile.

See Creating a Function Profile Using the GUI.

3. Create a service graph template.

See Creating a Layer 4 to Layer 7 Service Graph Template Using the GUI.

(Optional) Create an advanced service graph template instead of a standard service graph template.

See Creating a Layer 4 to Layer 7 Service Graph Template (Advanced).

4. Create a device.

See Creating a Device Using the GUI.

(Optional) Modify a device.

See Modifying a Device.

5. Apply a service graph template to endpoint groups (EPGs).

See Applying a Service Graph Template to Endpoint Groups Using the GUI.

Importing a Device Package Using the GUI

Before performing any configuration based on service graphs, you must download and install the appropriate device package in the Application Policy Infrastructure Controller (APIC) . A device package specifies to the APIC what devices you have and what the devices can do.

Step 1

Download an appropriate device package. You can find the list of partners at the following URL:
Click Here

This URL is the Partner Ecosystem page, where you can download the appropriate device package.

Step 2

Log in to the APIC as the provider administrator.

Step 3

On the menu bar, choose L4-L7 Services > Packages.

Step 4

In the Navigation pane, choose L4-L7 Service Device Types.

Step 5

In the Work pane, choose Actions > Import Device Package. The Import Device Package dialog box appears.

Step 6

Click Browse... and browse to the device package that you want to use.
For information about creating device packages, see the Cisco APIC Layer 4 to Layer 7 Device Package Development Guide.

Step 7

Click Open.

Step 8

Click Submit.

Creating a Function Profile Using the GUI

A Function Profile provides the default values for your service graph template. The following procedure explains how to create a new function profile.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose Tenant tenant_name > L4-L7 Services > Function Profiles.

Step 4

Right click Function Profiles and choose Create L4-L7 Services Function Profile.

Step 5

In the Create L4-L7 Services Function Profile dialog box, fill in the fields as required, except as specified below:

1. In the Profile Group drop-down list, choose Create Function Profile Group.
A profile group is a mechanism that allows you to group your profiles together for organizational purposes. For example, you may want to create a profile for your Web, legacy, or e-mail applications. You can create groups and then you can put your profiles into those groups. You may see that you already have an existing group available, but if you do not, then you can create a new one by naming it and providing a description in the Create L4-L7 Services Function Profile Group window.

Step 6

In the Create L4-L7 Services Function Profile Group dialog box, fill in the fields as required.

Step 7

Click Submit.
Now you have successfully completed and saved a profile group, which now appears in the Create L4-L7 Services Function Profile dialog box.

A profile is created for a particular service function. What you choose from the Device Function drop-down list in the Create L4-L7 Services Function Profile is the function for which you are writing a profile. From the drop-down list, you will see a list of device packages with service functions available in the Application Policy Infrastructure Controller (APIC) after you have imported the device packages.

Step 8

Back in the Create L4-L7 Services Function Profile dialog box, remove the check from the Copy Existing Profile Parameters check box.

Step 9

In the Device Function drop-down list, choose a device package that has a function. Options are displayed with the various parameters that are part of that function. The purpose of the profile is to provide the default values for the parameters.
Note:
At this point none of these parameters have any values, but you can add them, which are then used as the default values. The function profiles can be used by the graph templates after you provide these values. These values are applied to the graph template as default values, which means that if you use the graph templates and you do not provide a value for that particular parameter, then the APIC looks up the profile and see if the value is there. If it is there, then the APIC uses that.

Step 10

Add values in the Features and Parameters section at the bottom of the Create L4-L7 Services Function Profile window. There are two tabs, Basic Parameters and All Parameters. The Basic Parameters tab includes a list of parameters that are marked as mandatory (required) in the package. The All Parameters tab includes a list of the basic parameters as well as some additional / optional ones for advanced configurations. The reason we expose the Basic Parameters is because these are part of the basic configuration and the administrator is expected to fill these out. All Parameters are optional so unless you want to customize the functionality, these parameters can be left out.

Step 11

Click Submit. Now you have completed and saved your function profile.

- Using an Existing Function Profile to Create a New Function Profile Using the GUI

Using an Existing Function Profile to Create a New Function Profile Using the GUI

This procedure uses an existing function profile to create a new function profile.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose Tenant tenant_name > L4-L7 Services > Function Profiles.

Step 4

Right click Function Profiles and choose Create L4-L7 Services Function Profile.

Step 5

In the Create L4-L7 Services Function Profile dialog box, fill in the fields as required, except as specified below:

1. In the Profile drop-down list, choose an existing profile that is supplied by the vendor. The parameters are populated for your new profile based on the profile that you chose.

2. Change or add parameters to this existing profile as necessary.

Step 6

Click Submit.

Creating a Layer 4 to Layer 7 Service Graph Template Using the GUI

A service graph template is a sequence of Layer 4 to Layer 7 functions or devices and their associated configuration, which can be provided by using function profiles. The service graph template must be associated with a contract to be "rendered"—or configured—on the Layer 4 to Layer 7 device and on the fabric.

Before You Begin

- You must have configured a tenant.

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose Tenant tenant_name > L4-L7 Services > L4-L7 Service Graph Templates.

Step 4

In the Work pane, choose Actions > Create a L4-L7 Service Graph Template.

Step 5

In the Create a L4-L7 Service Graph Template dialog box, in the Device Clusters section, choose a device cluster.

Step 6

Complete the following fields:

Name

Description

Graph Name field

Enter the name of the service graph template.

Graph Type radio buttons

Choose to create a new service graph template or clone an existing service graph template.

Existing Graphs drop-down list

(Only for cloning an existing service graph template) Choose an existing service graph template to clone.

Step 7

(Only for creating a new service graph template) Drag a device from the Device Clusters section and drop it between the consumer endpoint group and provider endpoint group to create a service node.

Step 8

(Optional)(Only for cloning an existing service graph template) Remove the existing node and drag a different device cluster to the node area to create a service node.

Step 9

Click Submit.

Step 10

(Optional)In the Navigation pane. click the service graph template. The screen presents a graphic topology of the service graph template.

Modifying a Device

After you create a device, you can modify the device.

Note

To create a device or to add a device to an existing cluster, you must use the "Creating a Device" procedure.

Step 1

On the menu bar, click the TENANTS tab. The Tenant window appears.

Step 2

In the Navigation pane, expand the Tenant branch, expand the L4-L7 Services branch, and click L4-L7 Devices. The L4-L7 Devices window expands and displays the devices.

Step 3

Click the main device group you want to modify. The L4-L7 Devices window appears, showing the General page, which displays general information as well as connections and credentials for this device. In addition, you view the configuration state of the device.

Step 4

You can change many of the parameters in the sections of this General window.
You can change the path for the interfaces in this window, but you cannot add interfaces here.

1. To change the path, double-click on the path you want to change. The Properties window appears.

2. Complete the following fields:

Name

Description

Path drop-down list

Click the path you want to use.

Logical Interface drop-down list

Click external or internal, depending on the connector you are working with.

3. Click Submit.

Step 5

Return to the General window.

Step 6

Click the Parameters tab at the top of the General page. The screen the features and parameters available with this package and this device group. You see a tab with the Basic parameters displayed and another tab All Parameters that displays all the available parameters with your device package. (The basic parameters are included under all parameters.)

Step 7

In the Features section, click on the set of features for which you want to modify the parameters. The screen displays the parameters and features. The set of parameters changes depending on the specific package you are using and the specific feature you select.

Step 8

Supply or modify the values for the desired features as follows:
Note:   You must update the parent folder first.

1. Double-click in the field you want to modify.

2. Enter the required information in the fields that appear.

3. Click the Update button.
Note:
Click Reset to return these values to the previous values.

Step 9

To display or modify the parameters for a single device, expand the Tenant branch in the Navigation pane, expand the L4-L7 Services branch, and click L4-L7 Devices. The L4-L7 Devices window expands and displays the devices.

Step 10

Click the main device group to which the specific device belongs: The Navigation pane displays the devices in the main device group.

Step 11

Click the device for which you want to display or modify the parameters. The screen both displays a graphic topology for the specified device.

Step 12

Click the Parameters tab. The screen both displays the current features and parameters and allows you to change the values. You see a tab with the Basic parameters displayed and another tab All Parameters that displays all the available parameters with your device package. (The basic parameters are included under all parameters.)

Step 13

In the Features section, click on the set of features for which you want to modify the parameters. The screen displays the parameters and features for the single device. The set of parameters changes depending on the specific package you are using and the specific feature you select.

Step 14

Supply or modify the values for the desired features as follows:

1. Double-click in the field you want to modify.

2. Enter the required information in the fields that appear.

3. Click the Update button.
Note:
Click Reset to return these values to the previous values.

Applying a Service Graph Template to Endpoint Groups Using the GUI

The following procedure explains how to apply a service graph template to endpoint groups:

Before You Begin

You must have created the following things:

- Application endpoint groups

- A service graph template

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click the tenant's name.

Step 3

In the Navigation pane, choose Tenant tenant_name > L4-L7 Services > L4-L7 Service Graph Templates > template_name.

Step 4

In the Work pane, choose Actions > Apply L4-L7 Service Graph Template.
You will be associating a Layer 4 to Layer 7 service graph template to your consumer and provider endpoint groups.

Step 5

In the Apply L4-L7 Service Graph Template To EPGs dialog, in the EPG Information section, complete the following fields:

Name

Description

Consumer EPG/External Network drop-down list

Choose a consumer endpoint group.

Provider EPG/External Network drop-down list

Choose a provider endpoint group.

Step 6

In the Contract Information section, complete the following fields:

Name

Description

Contract radio buttons

Choose to create a contract or choose an existing contract.

Contract Name field

(Only for creating a contract) Enter the name of the contract.

No Filter (Allow All Traffic) check box

(Only for creating a contract) Put a check in the box to allow all traffic, or remove the check from the box to filter traffic.

Filter Entries

(Only for filtering traffic) Click + and enter the filter information, then click Update.

Existing Contract With Subjects drop-down list

(Only for choosing an existing contract) Choose an existing contract.

Step 7

Click Next.

Step 8

In the Device Clusters section, choose a device cluster.

Step 9

Complete the following field:

Name

Description

Graph Template drop-down list

Choose a graph template.

Step 10

(Optional) Remove the existing node and drag a different device cluster to the node area to create a service node.

Step 11

In the unmanaged information section, complete the following field:

Name

Description

Cluster Interface For Consumer Connector drop-down list

Choose an interface for the consumer connector.

Cluster Interface For Provider Connector drop-down list

Choose an interface for the provider connector.

General check box

Put a check in the box to be able to choose bridge domains.

BD For Consumer Connector drop-down list

(Only if you put a check in the General check box) Choose a bridge domain for the consumer connector. The bridge domain is used for the data path traffic.

BD For Provider Connector drop-down list

(Only if you put a check in the General check box) Choose a bridge domain for the provider connector. The bridge domain is used for the data path traffic.

Route Peering check box

Put a check in the box to enable route peering.

The Application Policy Infrastructure Controller (APIC) uses the chosen bridge domains for data path traffic between function nodes as required by the chosen service graph template. Refer to the online help for the service graph templates to learn more about how this bridge domain is used.

Step 12

(Only for managed devices) Click Next.

Step 13

(Only for managed devices) In the Parameters screen, in the Required Parameters tab, enter the names and values, as appropriate, for all of the required parameters.

Step 14

Click Finish. You now have an active service graph template. The APIC populates the Layer 4 to Layer 7 parameters based on the chosen function profile and colors the mandatory parameters in green if they are configured correctly.

Preface

This preface includes the following sections:

- Audience

- Document Conventions

- Related Documentation

- Documentation Feedback

- Obtaining Documentation and Submitting a Service Request

Audience

This guide is intended primarily for data center administrators with responsibilities and expertise in one or more of the following:

- Virtual machine installation and administration

- Layer 4 to Layer 7 Services installation and administration

- Switch and network administration

Document Conventions

Command descriptions use the following conventions:

Convention

Description

bold

Bold text indicates the commands and keywords that you enter literally as shown.

Italic

Italic text indicates arguments for which the user supplies the values.

[x]

Square brackets enclose an optional element (keyword or argument).

[x | y]

Square brackets enclosing keywords or arguments separated by a vertical bar indicate an optional choice.

{x | y}

Braces enclosing keywords or arguments separated by a vertical bar indicate a required choice.

[x {y | z}]

Nested set of square brackets or braces indicate optional or required choices within optional or required elements. Braces and a vertical bar within square brackets indicate a required choice within an optional element.

variable

Indicates a variable for which you supply values, in context where italics cannot be used.

string

A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Examples use the following conventions:

Convention

Description

screen font

Terminal sessions and information the switch displays are in screen font.

boldface screen font

Information you must enter is in boldface screen font.

italic screen font

Arguments for which you supply values are in italic screen font.

< >

Nonprinting characters, such as passwords, are in angle brackets.

[ ]

Default responses to system prompts are in square brackets.

!, #

An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

This document uses the following conventions:

Note

Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.

Caution

Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Warning

IMPORTANT SAFETY INSTRUCTIONS

This warning symbol means danger. You are in a situation that could cause bodily injury. Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents. Use the statement number provided at the end of each warning to locate its translation in the translated safety warnings that accompanied this device.

SAVE THESE INSTRUCTIONS

Related Documentation

The Application Centric Infrastructure documentation set includes the following documents that are available on Cisco.com at the following URL: Click Here .

Web-Based Documentation

- Cisco APIC Management Information Model Reference

- Cisco APIC Online Help Reference

- Cisco APIC Python SDK Reference

- Cisco ACI Compatibility Tool

- Cisco ACI MIB Support List

Downloadable Documentation

- Knowledge Base Articles (KB Articles) are available at the following URL: Click Here

- Cisco Application Centric Infrastructure Controller Release Notes

- Cisco Application Centric Infrastructure Fundamentals Guide

- Cisco APIC Getting Started Guide

- Cisco ACI Basic Configuration Guide

- Cisco ACI Virtualization Guide

- Cisco APIC REST API User Guide

- Cisco APIC Object Model Command Line Interface User Guide

- Cisco APIC NX-OS Style Command-Line Interface Configuration Guide

- Cisco APIC Faults, Events, and System Messages Management Guide

- Cisco ACI System Messages Reference Guide

- Cisco APIC Layer 4 to Layer 7 Services Deployment Guide

- Cisco APIC Layer 4 to Layer 7 Device Package Development Guide

- Cisco APIC Layer 4 to Layer 7 Device Package Test Guide

- Cisco ACI Firmware Management Guide

- Cisco ACI Troubleshooting Guide

- Cisco APIC NX-OS Style CLI Command Reference

- Cisco ACI Switch Command Reference, NX-OS Release 11.0

- Verified Scalability Guide for Cisco ACI

- Cisco ACI MIB Quick Reference

- Cisco Nexus CLI to Cisco APIC Mapping Guide

- Application Centric Infrastructure Fabric Hardware Installation Guide

- Cisco NX-OS Release Notes for Cisco Nexus 9000 Series ACI-Mode Switches

- Nexus 9000 Series ACI Mode Licensing Guide

- Cisco Nexus 9332PQ ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9336PQ ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9372PX and 9372PX-E ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9372TX ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9396PX ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9396TX ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 93128TX ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9504 NX-OS Mode Switch Hardware Installation Guide

- Cisco Nexus 9508 ACI-Mode Switch Hardware Installation Guide

- Cisco Nexus 9516 ACI-Mode Switch Hardware Installation Guide

Cisco Application Centric Infrastructure (ACI) Simulator Documentation

The following Cisco ACI Simulator documentation is available at Click Here .

- Cisco ACI Simulator Release Notes

- Cisco ACI Simulator Installation Guide

- Cisco ACI Simulator Getting Started Guide

Cisco Nexus 9000 Series Switches Documentation

The Cisco Nexus 9000 Series Switches documentation is available at Click Here .

Cisco Application Virtual Switch Documentation

The Cisco Application Virtual Switch (AVS) documentation is available at Click Here .

Cisco Application Centric Infrastructure (ACI) Integration with OpenStack Documentation

Cisco ACI integration with OpenStack documentation is available at Click Here .

Documentation Feedback

To provide technical feedback on this document, or to report an error or omission, please send your comments to apic-docfeedback@cisco.com. We appreciate your feedback.

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation at: Click Here

Subscribe to What’s New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation as an RSS feed and delivers content directly to your desktop using a reader application. The RSS feeds are a free service.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)