New and Changed Features

Collapsed Spine Architecture

Starting from release 2011, Contrail Networking supports collapsed spine, which is an architecture in which there is no defined leaf layer. In collapsed spine architecture, the Layer 3 IP-based underlay and the EVPN-VXLAN overlay, which are usually run on the leaf, are built on the spine switches.

For more information, see Collapsed Spine Architecture

Optimization of IRB Interfaces Creation in ERB Devices

In an ERB topology with ERB-UCAST-Gateway role configured on edge-routed bridging (ERB) switches, when creating a logical router, an integrated routing and bridging (IRB) interface is created for each associated VN on all ERB switches. IRB interfaces are created regardless of a local port or VPG in the associated VNs. This leads to a lot of unnecessary IRB and VRF configurations associated to the logical router being pushed to the ERB switches.

Starting from release 2011, Contrail Networking checks if a VPG is attached to the VN in an ERB switch with ERB-UCAST-Gateway role configured, before pushing IRB interface configuration associated with the logical router to the switch. Only if a VPG is attached to the VN, the IRB interface configuration is pushed to the ERB switch. The routing instance is not created if there are no VPGs.

For more information on ERB, see Edge-Routed Bridging for QFX Series Switches.

Support for Fabric Telemetry Alarms

In Contrail Networking Release 2011, the Fabrics page displays additional detail about the health of your devices and interfaces, gathering data from telemetry profiles configured on these devices. These pages will show if any key performance indicators (KPIs) have crossed a threshold value. You can also configure metrics and assign telemetry profiles from the Fabrics Overview page.

For more information, see Viewing Telemetry KPI Alarms for Fabric Devices and Ports.

Support for Layer 2 DCI Functionality

You can automate data center interconnect (DCI) of two different data centers. Multiple tenants connected to a logical router in a data center can exchange routes with tenants connected to a logical router in another data center. With Contrail Networking Release 2011, layer 2 DCI functionality is also supported. You can create a layer 2 DCI of two different data centers from the Overlay>Interconnects>Data Center Interconnect page of the Contrail Command UI.

For more information, see Data Center Interconnect.

Support for Protocol-Based Telemetry Profiles

Contrail Networking Release 2011 supports gRPC, Netconf, and SNMP protocol-based telemetry profiles. Contrail Insights collects key performance indicators (KPIs) from network devices using preconfigured sensors and commands.

For more information, see Contrail Insights Flows in Contrail Command.

Support for EVPN Type-5 Routes in Logical Router

Starting from Contrail Networking Release 2011, the Contrail vRouter forwards incoming EVPN Type-5 route updates to a logical router (LR) deployed on a spine device in a fabric. This enables the LR to connect to third party physical routers and virtual machine interfaces hosted in Contrail clusters. In previous releases, the LR supports L3 traffic flow between virtual machines (VM) and bare metal servers (BMS) that are deployed in interconnected virtual networks (VN). However, when there is a default route (0.0.0.0/0) coming from a BGP peer of the tenant VN, the routing topology is disrupted due to duplicate default routes in the tenant VN VRF. In release 2011, vRouter does not add default route in VN VRF, when a virtual network is connected to a logical router.

In release 2011, the Contrail vRouter enables the LR to support inter-subnet routing between the Contrail VNs. The vRouter agent injects the non-/ 32 VN subnet route for the IPAM subnet of all the other remote VNs that are connected to the LR. This enables the vRouter agent to function without adding a 0.0.0.0/0 route to the tenant VRF.

In release 2011, Contrail Networking also provides more connectivity to customer PNF devices. An unamanged PNF device can be connected to a QFX Series device to provide connectivity to customer private networks. Instead of adding default routes, Contrail Networking adds subnet routes to the virtual networks connected to a LR. The route updates received by the logical router VRF is extended to the default EVPN route table. The Contrail vRouter agent then extends the incoming routes in all the connected tenant VRFs so that the tenant VRFs can reach the PNF subnets using a QFX Series device as next-hop.

Support for Adding or Deleting Flow Collector Nodes in Contrail Command

Contrail Networking Release 2011 supports adding, removing, and reconfiguring collector nodes (also known as sFlow nodes) after the system is up and running. Prior to this release, collector nodes could only be added during provisioning.

For more information, see Adding or Deleting Flow Collector Nodes in Contrail Command.

Support for Intel DDP in vRouter for Fortville NICS

Starting with Contrail Networking Release 2011, the Contrail vRouter supports Intel dynamic device personalization (DDP) technology, which enables faster processing of packets with MPLSoGRE encapsulation. The Intel DDP technology is supported only in Intel Fortville Series NICs.

For more information, see Contrail DPDK vRouter Support for Intel DDP Technology in Fortville NICs.

Support for Topology Discovery during Device Onboarding

Contrail Networking Release 2011 supports topology discovery when you run the onboard device job. After a device has been onboarded, you can view the fabric interfaces from the Physical Interfaces page of the device.

For more information, see Device Import.

Retaining the AS Path Attribute in a Service Chain

Starting with Contrail Networking Release 2011, you can configure the AS path to be retained in the routes re-originated from the destination VN to the source VN in a service chain. You also have the ability to enable or disable the path retention for selected service chains. You can enable or disable the Retain AS Path option while configuring the network policy in the Overlay > Network Policies > Create Network Policy page.

For more information, see Retaining the AS Path Attribute in a Service Chain.

Integrating OpenStack with Contrail Networking Fabric by using Modular Layer 2 (ML2) Neutron Plug-in

Contrail Networking Release 2011 supports integrating OpenStack with Contrail Networking Fabric. A Modular Layer 2 (ML2) Neutron plug-in is deployed for this integration. The ML2 plug-in enables OpenStack to use various layer 2 networking technologies that are found in complex real-world data centers.

For more information, see Understanding OpenStack-Contrail Networking Fabric Integration.

Support for vRouter MAC Address - IP Address Bond Learning and BFD Health Check for Pods

Starting with Contrail Networking Release 2011, the Contrail vRouter dynamically learns the MAC address - IP address binding of the pods deployed on a virtual machine (VM). The vRouter learns the MAC address - IP address binding of the pods to enable an efficient pod to pod communication. Also, Contrail Networking supports Bidirectional Forwarding and Detection (BFD) based health check to verify the liveliness of a pod.

For more information, see Contrail vRouter MAC Address - IP Address Bond Learning and Bidirectional Forwarding and Detection Health Checking for Pods on Virtual Machines.

Support for Superspine Role

Starting with Rrelease 2011, Contrail Networking supports the superspine role. Devices with the role superspine can function as either a lean device that provides only IP forwarding or as a route reflector that can establish iBGP sessions with the peers. To configure a device as superspine, you need to assign the Physical Role as superspine and overlay role as lean or Route-Reflector.

For more information, see Support for Superspine Role.

Support for QFX5220-32CD and QFX5220-128C as Spine and Superspine Devices

Starting with Contrail Networking Release 2011, you can configure the QFX5220-32CD and QFX5220-128C devices as spine and superspine devices. They can be assigned the lean and Route-Reflector roles. The QFX5220-32CD and QFX5220-128C devices cannot be configured as leaf devices and software image upgrade is not supported on them.

For more information, see Contrail Networking Supported Hardware Platforms and Associated Roles And Node Profiles and Support for Superspine Role.

Support for OpenStack Ussuri and Ubuntu Version 20.04

Starting with Contrail Networking Release 2011, Contrail Networking supports OpenStack Ussuri with Ubuntu version 18.04 (Bionic Beaver) and Ubuntu version 20.04 (Focal Fossa). The installation process is same as of installing Contrail Networking with OpenStack by Using Juju Charms.

For details, see Installing Contrail with OpenStack by Using Juju Charms and Bundle Reference File.

Support for Sandump Tool on Windows Machines

Starting with Contrail Networking Release 2011, Sandump tool with Wireshark is available on Windows machines. Sandump tool captures the Sandesh messages from netlink connection between the Agent and the vRouter (only DPDK mode) and, provides detailed interpretation of all the captured bytes.​ For details, see Using Sandump Tool​.

Support for agent_header.lua Wireshark Plugin in Windows OS Computers

Starting with Contrail Networking Release 2011, you can also use the agent_header.lua Wireshark plugin in Windows OS computers, which enables you analyze the packets exchanged between vRouter data plane and vRouter agent on the pkt0 interface.

For more information, see Using the Wireshark Plugin to Analyze Packets Between vRouter and vRouter Agent on pkt0 Interface.

Upgrade Contrail Networking using Red Hat Fast Forward Upgrade Procedure

Starting with Contrail Release 2011, you can use a combined procedure to upgrade Red Hat OpenStack Platform (RHOSP) from RHOSP 13 to RHOSP 16.1 by leveraging Red Hat Fast Forward Upgrade (FFU) procedure while simultaneously upgrading Contrail Networking from Release 19xx to Release 2011. For details, see Upgrading Contrail Networking Release 19xx with RHOSP13 to Contrail Networking Release 2011 with RHOSP16.1.

Support for Red Hat OpenShift 4.5

Starting in Contrail Networking Release 2011, you can enable Contrail Networking as the Container Network Interface (CNI) in environments using Red Hat OpenShift 4.5. Red Hat OpenShift is a platform as a service product offering from Red Hat composed of containerized software elements that is orchestrated using Kubernetes. Earlier versions of Red Hat OpenShift are supported by earlier versions of Contrail Networking; see Supported Platforms.

For more information on Red Hat Openshift 4.5 in Contrail Networking, see How to Install Contrail Networking and Red Hat OpenShift 4.5.

Support for KubeVirt in Kubernetes Environments

Starting in Contrail Networking Release 2011, you can use KubeVirt in Kubernetes-orchestrated environments that use Contrail Networking as the Container Networking Interface (CNI). KubeVirt is a virtualization add-on to Kubernetes that allows virtual machines (VMs) to run alongside the application containers present in Kubernetes environments.

For more information, see How to Enable Virtualization with KubeVirt in Environments Using Kubernetes with a Contrail Cluster.

Support for Keystone Authentication in Kubernetes Environments Using Juju

Starting in Contrail Networking Release 2011, you can use the Keystone authentication service in OpenStack for authentication in environments that contain cloud networks using both Openstack and Kubernetes orchestrators when the Kubernetes environment is running Juju. This capability simplifies authentication in mixed cloud environments and is available when the cloud networks are both using Contrail Networking.

For more information, see How to Enable Keystone Authentication in a Juju Cluster within a Kubernetes Environment.

Support for Installing Contrail Insights and Contrail Insights Flows on Juju Cluster

Contrail Networking Release 2011 supports installing Contrail Insights and Contrail Insights Flows on Juju cluster after Contrail Networking and Contrail Command are installed. For more information see How to Deploy Contrail Command and Import a Cluster Using Juju.

Support for Custom Names for Privileged Ports and VXLANs

In Contrail Networking Release 2011, this is a beta feature that allows you to assign custom names to privileged ports and VXLANs in order to make them easier to identify in the topology mapping. When you make queries for traffic flows in the Topology View, the custom name displays versus the port number or VXLAN ID.

For more information, see Assign Custom Names to Privileged Ports and VXLAN IDs.

Support for contrail-vrouter-utils package in the Contrail Tools Container

Starting with Contrail Networking Release 2011, the contrail-vrouter-utils package is available only in the contrail-tools container. You must use the contrail-tools container to execute tools like vif, nh, rt, and so on available in the contrail-vrouter-utils package. In previous releases, the contrail-vrouter-utils package is available in the contrail-vrouter-agent and contrail-vrouter-dpdk container. You can no longer use the contrail-vrouter-agent and contrail-vrouter-dpdk containers to execute the tools available in the contrail-vrouter-utils package.

Support for Netronome SmartNIC vRouter for Juju Charms Deployment—Evaluation Purposes Only

Starting with Contrail Networking Release 2011, Contrail Networking supports Netronome Agilio CX for Contrail Networking deployment with Juju charms. This feature enables increased packets per second (PPS) capacity of Contrail vRouter datapath allowing applications to reach their full processing capacity. Additionally, it allows to reclaim CPU cores from Contrail vRouter off-loading permitting more VMs and VNFs to be deployed per server. For details, see Using Netronome SmartNIC vRouter with Contrail Networking and Juju Charms.