- play_arrow Overview
- play_arrow Understanding Contrail Controller
-
- play_arrow Installing and Upgrading Contrail
- play_arrow Supported Platforms and Server Requirements
- play_arrow Installing Contrail and Provisioning Roles
- Introduction to Containerized Contrail Modules
- Introduction to Contrail Microservices Architecture
- Downloading Installation Software
- Overview of contrail-ansible-deployer used in Contrail Command for Installing Contrail with Microservices Architecture
- Installing Contrail with OpenStack and Kolla Ansible
- Configuring the Control Node with BGP
- Contrail Global Controller
- Role and Resource-Based Access Control
- play_arrow Installation and Configuration Scenarios
- Setting Up and Using a Simple Virtual Gateway with Contrail 4.0
- Configuring MD5 Authentication for BGP Sessions
- Configuring the Data Plane Development Kit (DPDK) Integrated with Contrail vRouter
- Configuring Contrail DPDK vRouter to Run in a Docker Container
- Configuring Single Root I/O Virtualization (SR-IOV)
- Configuring Virtual Networks for Hub-and-Spoke Topology
- Configuring Transport Layer Security-Based XMPP in Contrail
- Configuring Graceful Restart and Long-lived Graceful Restart
- Remote Compute
- Dynamic Kernel Module Support (DKMS) for vRouter
- play_arrow Upgrading Contrail Software
- play_arrow Backup and Restore Contrail Software
- play_arrow Multicloud Contrail
- play_arrow Using Contrail with Kubernetes
- Contrail Integration with Kubernetes
- Installing and Managing Contrail 5.0 Microservices Architecture Using Helm Charts
- Provisioning of Kubernetes Clusters
- Using Helm Charts to Provision Multinode Contrail OpenStack Ocata with High Availability
- Using Helm Charts to Provision All-in-One Contrail with OpenStack Ocata
- Accessing a Contrail OpenStack Helm Cluster
- Frequently Asked Questions About Contrail and Helm Charts
- Contrail Deployment with Helm
- Verifying Configuration for CNI for Kubernetes
- Kubernetes Updates to IP Fabric
- Implementation of Kubernetes Network Policy with Contrail Firewall Policy
- play_arrow Using VMware vCenter with Containerized Contrail
- vCenter Integration for Contrail Release 5.0
- vCenter Integration for Contrail Release 5.0.1
- vCenter Integration for Contrail Release 5.0.2
- Underlay Network Configuration for ContrailVM
- Using the Contrail and VMware vCenter User Interfaces to Manage the Network For Contrail Releases 5.0 and 5.0.1
- Using the Contrail and VMware vCenter User Interfaces to Manage the Network For Contrail Release 5.0.2
- Integrating Contrail Release 5.0.X with VMware vRealize Orchestrator
- Installing and Provisioning Contrail VMware vRealize Orchestrator Plugin
- play_arrow Using Contrail with Red Hat
- play_arrow Contrail and AppFormix Kolla/Ocata OpenStack Deployment
- Contrail and AppFormix Deployment Requirements
- Preparing for the Installation
- Run the Playbooks
- Accessing Contrail in AppFormix Management Infrastructure in UI
- Notes and Caveats
- Example Instances.yml for Contrail and AppFormix OpenStack Deployment
- Installing AppFormix for OpenStack
- Installing AppFormix for OpenStack in HA
- play_arrow Using Contrail with Juju Charms
- play_arrow Contrail Command
- play_arrow Extending Contrail to Physical Routers, Bare Metal Servers, Switches, and Interfaces
- Understanding Bare Metal Server Management
- Configuring High Availability for the Contrail OVSDB ToR Agent
- Using Device Manager to Manage Physical Routers
- SR-IOV VF as the Physical Interface of vRouter
- Using Gateway Mode to Support Remote Instances
- REST APIs for Extending the Contrail Cluster to Physical Routers, and Physical and Logical Interfaces
- play_arrow Contrail for Data Center Automation and Fabric Management
-
- play_arrow Contrail Security
- play_arrow Contrail Security
-
- play_arrow Monitoring and Troubleshooting Contrail
- play_arrow Configuring Traffic Mirroring to Monitor Network Traffic
- play_arrow Understanding Contrail Analytics
- play_arrow Configuring Contrail Analytics
- Analytics Scalability
- High Availability for Analytics
- System Log Receiver in Contrail Analytics
- Sending Flow Messages to the Contrail System Log
- Ceilometer Support in a Contrail Cloud
- User Configuration for Analytics Alarms and Log Statistics
- Alarms History
- Node Memory and CPU Information
- Role- and Resource-Based Access Control for the Contrail Analytics API
- Configuring Analytics as a Standalone Solution
- Configuring Secure Sandesh and Introspect for Contrail Analytics
- play_arrow Using Contrail Analytics to Monitor and Troubleshoot the Network
- Monitoring the System
- Debugging Processes Using the Contrail Introspect Feature
- Monitor > Infrastructure > Dashboard
- Monitor > Infrastructure > Control Nodes
- Monitor > Infrastructure > Virtual Routers
- Monitor > Infrastructure > Analytics Nodes
- Monitor > Infrastructure > Config Nodes
- Monitor > Networking
- Query > Flows
- Query > Logs
- Understanding Flow Sampling
- Example: Debugging Connectivity Using Monitoring for Troubleshooting
- play_arrow Common Support Answers
-
- play_arrow Contrail Commands and APIs
- play_arrow Contrail Commands
- play_arrow Contrail Application Programming Interfaces (APIs)
-
Service Chain Version 2 with Port Tuple
Starting with Contrail 3.0, the user can create a port-tuple object for binding service instances to ports.
Overview of Port Tuple
In previous versions of Contrail, when a service instance is created for a virtual machine (VM)-based service, the service monitor creates one or more VM objects and creates a port for each VM object. Each VM object is a placeholder for binding a service instance to a port. The VM object also acts as a placeholder for the instance ID when using equal-cost multipath (ECMP).
Using the VM object as a placeholder doesn't add value beyond binding information between the service instance object and the port objects. By using a port-tuple object, the service instance can be linked directly to the port objects, eliminating the need to create a VM object. This simplifies the implementation of service instance objects, and also allows integration with Heat templates.
With a port-tuple object, the user can create ports and pass the port information when creating a service instance. The ports can be created as part of a VM launch from Nova or without using a VM launch. The ports are linked to a port-tuple object that is a child of a service instance. This functionality can also be leveraged in Heat stacks. See Figure 1.

Service Chain Version 2 Sample Workflow
With Contrail service templates Version 2, the user can create ports and bind them to a VM-based or container-based service instance, by means of a port-tuple object. All objects created with the Version 2 service template are visible to the Contrail Heat engine, and are managed by Heat.
The following shows the basic workflow steps for creating a port tuple and service instance that will be managed by Heat:
Create a service template. Select 2 in the Version field.
Create a service instance for the service template just created.
Create a port-tuple object.
Create ports, using Nova VM launch or without a VM launch.
Label each port as
left, right, mgmt
, and so on, and add the ports to the port-tuple object.Use a unique label for each of the ports in a single port tuple. The labels
left
andright
are used for forwarding.Link the port tuple to a service instance.
Launch the service instance. This creates the necessary objects in the Contrail database.
Port-tuple is not supported on transparent service instance, whether active/active, active/standby, or scale-out.
- Service Chain with Equal-Cost Multipath in Active-Active Mode
- Service Chain Active-Standby Mode with Allowed Address Pair
- Service Chain with Static Route Table
Service Chain with Equal-Cost Multipath in Active-Active Mode
Equal-cost multipath (ECMP) can be used to distribute traffic
across VMs. To support ECMP in the service chain, create multiple
port tuples within the same service instance. The labels should be
the same for the VM ports in each port tuple. For example, if port
tuple 1 uses the labels left
and right
, then port tuple 2 in the same service instance
should also use the labels left
and right
for its ports.
When there are multiple port tuples, the default mode of operation
is active-active
.
Service Chain Active-Standby Mode with Allowed Address Pair
To support active-standby
mode, you
must configure an allowed address pair on the interfaces. The active-standby
is used as the high availability mode
in the allowed address pair. The allowed address pair is configured
as part of the service instance for a particular VM port label. For
example, if the allowed address pair is configured in a service instance
for the port with the label left
, then
all of the port-tuple VM ports with the label left
will use the allowed address pair high availability mode.
Allowed Address Pair
An allowed address pair extension is an OpenStack feature supported by Contrail.
By default, there is no way to specify additional MAC/IP address pairs that are allowed to pass through a port in Neutron, because ports are locked down to their MAC address and the fixed IPs associated with their port for anti-spoofing reasons. This locking can sometimes prevent protocols such as VRRP from providing a high availability failover strategy. Using the allowed address pair extension enables additional IP/MAC pairs to be allowed through ports in Neutron.
In Contrail, you can configure allowed address pairs in the service instance configuration, using Configure > Services > Service Instances > Allowed Address Pair, see Figure 2.

For more information about OpenStack allowed address pairs, see https://specs.openstack.org/openstack/neutron-specs/specs/api/allowed_address_pairs.html .
Service Chain with Static Route Table
The service chain Version 2 also supports static route tables.
A static route table is configured similar to how the allowed address
pair is configured, except with using the label right
. The route table will be attached to the correct VM ports of the
port tuples, based on the configuration of the port with the label right
.
Service Chain with Health Check
Service chain Version 2 also allows service instance health check configuration on a per interface label. This is used to monitor the health of the service.
For more information about the service instance health check, see Health Check Object.