- 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)
-
Source Network Address Translation (SNAT)
Overview
Source Network Address Translation (source-nat or SNAT) allows traffic from a private network to go out to the internet. Virtual machines launched on a private network can get to the internet by going through a gateway capable of performing SNAT. The gateway has one arm on the public network and as part of SNAT, it replaces the source IP of the originating packet with its own public side IP. As part of SNAT, the source port is also updated so that multiple VMs can reach the public network through a single gateway public IP.
The following diagram shows a virtual network with the private subnet of 10.1.1.0/24. The default route for the virtual network points to the SNAT gateway. The gateway replaces the source-ip from 10.1.1.0/24 and uses its public address 172.21.1.1 for outgoing packets. To maintain unique NAT sessions the source port of the traffic also needs to be replaced.

Neutron APIs for Routers
OpenStack supports SNAT gateway implementation through its Neutron APIs for routers. The SNAT flag can be enabled or disabled on the external gateway of the router. The default is True (enabled).
The OpenContrail plugin supports the Neutron APIs for routers and creates the relevant service-template and service-instance objects in the API server. The service scheduler in OpenContrail instantiates the gateway on a randomly-selected virtual router. OpenContrail uses network namespace to support this feature.
Example Configuration: SNAT for Contrail
The SNAT feature is enabled on OpenContrail through Neutron API calls.
The following configuration example shows how to create a test network and a public network, allowing the test network to reach the public domain through the SNAT gateway.
Network Namespace
Setting the external gateway is the trigger for OpenContrail to set up the Linux network namespace for SNAT.
The network namespace can be cleared by issuing the following Neutron command:
neutron router-gateway-clear r1
Using the Web UI to Configure Routers with SNAT
You can use the Contrail user interface to configure routers for SNAT and to check the SNAT status of routers.
To enable SNAT for a router, go to Configure > Networking > Routers. In the list of routers, select the router for which SNAT should be enabled. Click the Edit cog to reveal the Edit Routers window. Click the check box for SNAT to enable SNAT on the router.
The following shows a router for which SNAT has been Enabled.

When a router has been Enabled for SNAT, the configuration can be seen by selecting Configure > Networking > Routers. In the list of routers, click open the router of interest. In the list of features for that router, the status of SNAT is listed. The following shows a router that has been opened in the list. The status of the router shows that SNAT is Enabled.

You can view the real time status of a router with SNAT by viewing the instance console, as in the following.

Using the Web UI to Configure Distributed SNAT
The distributed SNAT feature allows virtual machines to communicate with the IP fabric network using the existing forwarding infrastructure for compute node connectivity. This functionality is achieved through port address translation of virtual machine traffic using the IP address of the compute node as the public address.
The following distributed SNAT use case is supported:
Virtual networks with distributed SNAT enabled can communicate with the IP fabric network. The session must be initiated from a virtual machine. Sessions initiated from the external network are not supported.
Distributed SNAT is supported only for TCP and UDP, and you can configure discrete port ranges for both protocols.
A pool of ports is used for distributed SNAT. To create a pool of ports, go to Configure > Infrastructure > Global Config. The following shows an example of a port range used for port address translation.

To use distributed SNAT, you must enable SNAT on the virtual network. To enable SNAT on the virtual network, go to Configure > Networking > Networks. The following shows a virtual network for which SNAT has been enabled under Advanced Options.
