- 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)
-
Using the Contrail Heat Template
Heat is the orchestration engine of the OpenStack program. Heat enables launching multiple cloud applications based on templates that are comprised of text files.
Introduction to Heat
A Heat template describes the infrastructure for a cloud application, such as networks, servers, floating IP addresses, and the like, and can be used to manage the entire life cycle of that application.
When the application infrastructure changes, the Heat templates can be modified to automatically reflect those changes. Heat can also delete all application resources if the system is finished with an application.
Heat templates can record the relationships between resources, for example, which networks are connected by means of policy enforcements, and consequently call OpenStack REST APIs that create the necessary infrastructure, in the correct order, needed to launch the application managed by the Heat template.
Heat Architecture
Heat is implemented by means of Python applications, including the following:
heat-client
—The CLI tool that communicates with theheat-api
application to run Heat APIs.heat-api
—Provides an OpenStack native REST API that processes API requests by sending them to the Heat engine over remote procedure calls (RPCs).heat-engine
—Responsible for orchestrating the launch of templates and providing events back to the API consumer.
Support for Heat Version 2 Resources
Starting with Contrail Release 3.0.2, Contrail Heat resources
and templates are autogenerated from the Contrail schema, using Heat
Version 2 resources. Contrail Release 3.0.2 is the minimum required
version for using Heat with Contrail in 3.x releases. The Contrail
Heat Version 2 resources are of the following hierarchy: OS::ContrailV2::<ResourceName>
.
The generated resources and templates are part of the Contrail Python package, and are located in the following directory in the target installation:
/usr/lib/python2.7/dist-packages/vnc_api/gen/heat/
The heat/ directory has the following subdirectories:
resources/—Contains all the resources for the contrail-heat plugin, which runs in the context of the Heat engine service.
templates/—Contains sample templates for each resource. Each sample template presents every possible parameter in the schema. Use the sample templates as a reference when you build up more complex templates for your network design.
env/—Contains the environment for input to each template.
The following contains a list of all the generated plug-in resources
that are supported by contrail-heat
in
Contrail Release 3.0.2 and greater:
https://github.com/Juniper/contrail-heat/tree/master/generated/resources
The following contains a list of new example templates:
https://github.com/Juniper/contrail-heat/tree/master/contrail_heat/new_templates
Deprecation of Heat Version 1 Resources
Heat Version 1 resources within the hierarchy OS::Contrail::<ResourceName>
are being deprecated, and you should not create new service chains
using the Heat Version 1 templates.
Heat Version 2 with Service Chaining and Port Tuple Sample Workflow
With Contrail service templates Version 2, the user can create ports and bind them to a virtual machine (VM)-based service instance, by means of a port-tuple object. All objects created with the Version 2 service template are directly visible to the Contrail Heat engine, and are directly 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 named left and right are used for forwarding.
Link the port tuple to a service instance.
Launch the service instance.
Example: Creating a Service Template Using Heat
The following is an example of how to create a service template using Heat.
Define a template to create the service template.
content_copy zoom_out_mapservice_template.yaml heat_template_version: 2013-‐05-‐23 description: > HOT template to create a service template parameters: name: type: string description: Name of service template mode: type: string description: service mode type: type: string description: service type image: type: string description: Name of the image flavor: type: string description: Flavor service_interface_type_list: type: string description: List of interface types shared_ip_list: type: string description: List of shared ip enabled-‐disabled static_routes_list: type: string description: List of static routes enabled-‐disabled resources: service_template: type: OS::ContrailV2::ServiceTemplate properties: name: { get_param: name } service_mode: { get_param: mode } service_type: { get_param: type } image_name: { get_param: image } flavor: { get_param: flavor } service_interface_type_list: { "Fn::Split" : [ ",", Ref: service_interface_type_list ] } shared_ip_list: { "Fn::Split" : [ ",", Ref: shared_ip_list ] } static_routes_list: { "Fn::Split" : [ ",", Ref: static_routes_list ] } outputs: service_template_fq_name: description: FQ name of the service template value: { get_attr: [ service_template, fq_name] } }
Create an environment file to define the values to put in the variables in the template file.
content_copy zoom_out_mapservice_template.env parameters: name: contrail_svc_temp mode: transparent type: firewall image: cirros flavor: m1.tiny service_interface_type_list: management,left,right,other shared_ip_list: True,True,False,False static_routes_list: False,True,False,False
Create the Heat stack by launching the template and the environment file, using the following command:
content_copy zoom_out_mapheat stack create stack1 –f service_template.yaml –e service_template.env
OR use this command for recent versions of OpenStack
content_copy zoom_out_mapopenstack stack create -e <env-file-name> -t <template-file-name> <stack-name>