New and Changed Features

Support for Red Hat OpenStack Platform 17.1

Starting from Contrail Networking Release 21.4.L4, Contrail Networking supports Red Hat OPenStack Platform 17.1 without virtualization (neither KVM nor RHV). Prior to this enhancement, Contrail Networking was supported in environments with hosts using Kernel-based Virtual Machine (KVM) only. For more information about this feature, see Setting Up Contrail with Red Hat OpenStack 17.1.

Support for Neutron Port Binding API

Contrail Networking Release 21.4.L4 supports Openstack Neutron Port Binding API. OpenStack Neutron uses new port binding API to assist with live migration scenarios and has deprecated the old methodology which will impact live migration of a virtual machine to work in RHOSP 17.

For more information about this feature, see Neutron Port Binding API.

Support to Detach and Attach a Tagged as well as Untagged Virtual Machine Interface to a Virtual Port Group

Starting from Contrail Networking Release 21.4.L4, you can detach a tagged virtual machine interface from a virtual port group as well as attach a tagged virtual machine interface to a virtual port group. for more information about the procedure, see How to Detach and Attach a VMI to VPG.

Support for Dynamic MAC IP Learning for IPv6

A virtual machine deployed on OpenStack hosts multiple pods with their own MAC IP addresses. As these MAC IP addresses are assigned by an external application, Contrail Networking is not aware of the MAC IP addresses of these pods. However, to support pod to pod communication over OpenStack managed IaaS network, Contrail's vrouter must learn the MAC IP bindings of pods and share them with SDN gateway using IP-VPN and EVPN address families. Thus, Contrail Networking Release 21.4.L4 supports dataplane learning of MAC IP addresses reachable over virtual machines interfaces. (for IPv4, IPv6 and dualstack).

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

Support for MAC IP Learning on same MAC Addresses

Contrail Networking Release 21.4.L4 supports MAC IP learning of IPv4 and IPv6 routes, where the pods have the same MAC address as that of the VMI that the route is learnt from.

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

Support for MAC IP Learning on Sub-Interfaces

Contrail Networking Release 21.4.L4 supports MAC IP learning of IPv4 and IPv6 routes of pods learnt on sub-interfaces. The pods can either use IPvlan or Macvlan interface and IP address family of IPvlan or Macvlan interface should be same as that of sub-interface.

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

Support for Dual Stacked Sub-Interfaces

Service providers cannot continue to provide globally routable IPv4 addresses to its customers as it is not practically feasible to get new globally routable IPv4 addresses. However, to expand their networks they must continue to serve their existing IPv4 customers and new IPv6 customers, all of whom primarily try to reach IPv4 destinations. Thus, IPv4 and IPv6 must coexist, and their coexistence must be transparent to the end users.

A dual-stack device is a device with network interfaces that can originate and understand both IPv4 and IPv6 packets. Contrail Networking Release 21.4.L4 supports MAC-IP learning of dual-stacked pods.

Note:

• If you are planning to dual stack all of your network devices, the interfaces need both an IPv6 and an IPv4 address. If you do not have an abundant supply of IPv4 addresses to apply to your devices, you can still use dual stacking. However, you need to conserve the supply of IPv4 addresses by using Network Address Translation (NAT). Building dual-stacked networks with a mix of global IPv6 addresses and NAT-ed IPv4 addresses is quite feasible. Some specific solutions include Carrier-Grade NAT (CGN), NAT44(4), NAT64, NAT464, and dual-stack lite.

• The IP address of IPvlan and Macvlan should be of the same address family as its parent. For example, an IPvlan created on IPv4 should have IP address family same as its parent, i.e. IPv4 and similarly, an IPvlan created on IPv6 should have IP address family same as its parent, i.e. IPv6. If IPvlan interface is created on the sub-interface then IPvlan interface should have same address family as sub-interface.

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

Support to Apply non 1500 byte default MTU to VNs

Contrail Networking Release 21.4.L3 supports and implements MTU property within tenant and virtual network resources based on the priority from highest to lowest as follows:

1. Explicitly defined virtual network MTU, if provided
2. Per-tenant defined default MTU, if virtual network MTU is not defined explicitly
3. Default 1500 bytes, if no MTU is set per-tenant

The per-tenant MTU value can be configured and updated without impacting Contrail's current default behaviour. The default MTU per-tenant is 'None' and a default 1500 bytes MTU is assigned to any new virtual network for which no new explicit MTU is defined.

If a virtual network is created with zero MTU, then the MTU specified at the time of creating virtual network is is assigned. In case, MTU is not specified then its default value is applied.

Note: Only Contrail Command user interface supports this feature.

Deterministic Route Distinguisher Support on vRouter

Starting in Contrail Networking Release 21.4.L3, the configuration server generates a unique Routing Instance ID (RI-ID) every time a new Virtual Routing and Forwarding (VRF) ID is created. This RI-ID is applicable to routes using Route Distinguisher (RD) and is within the range 11 - 4294967296. An RI-ID is presented as routing_instance_id:id. For example, routing_instance_id:11. Using this RI-ID, an agent creates a deterministic RD, and it is presented as <compute-node-ip>:<unique-id-generated-by-config-server>. Here, RD value (<compute-node-ip>:11) generated in previous example is used.

The RD value 0 is reserved for default VRF, 'vrf : default-domain:default-project:ip-fabric:__default__' as the default VRF does not have any virtual network. And, RD value -1 is reserved to indicate that an invalid RD configuration is received from the configuration server.

This enhancement improves network performance after Contrail vRouter restarts by allowing RI-ID to remain unchanged through restart. The persistent RI-ID is already recognized by the network, simplifying the vRouter restart process for the vRouter and the cloud networking environment.

Support for Canonical Openstack Multi-model

Contrail Networking Release 21.4.L3 supports Canonical Openstack Multi-model deployment. Users can upgrade from Contrail Networking Release 21.4.L2 to Contrail Networking Release 21.4.L3.

For information on performing upgrading in multi-model, see Updating Contrail Networking using Zero Impact Upgrade Procedure in a Canonical Openstack Multi-model Deployment with Juju Charms.

Support for Mellanox CX6

Starting in Contrail Networking Release 21.4.L3, the ansible deployer of Contrail networking supports Mellanox CX6 with DPDK version 22.11.

Fast Forward Upgrade Support for Environments Using Red Hat Openstack Release 13 and Contrail Networking Release 1912.L4

Starting in Contrail Networking Release 21.4.L2, you can perform a Fast Forward Upgrade (FFU) from an environment using Contrail Networking Release 1912.L4 in Red Hat Openstack Release 13 to an environment using Contrail Networking Release 21.4.L2 in Red Hat Openstack Release 16.2.4. The FFU provides users with an opportunity to upgrade between long-life versions of Red Hat OpenStack that are multiple Openstack versions apart from one another while also upgrading Contrail Networking using the same process.

For information on performing this FFU, see Fast Forward Upgrade: Updating Contrail Networking 1912.L2 and Red Hat OpenStack 13 to Contrail Networking 21.4.L2 and Red Hat Openstack 16.2.

BGP as a Service (BGPaaS) Support for Remote Compute External Controllers

Starting in Contrail Networking Release 21.4.L2, you can configure BGP as a Service (BGPaaS) in remote compute clusters. You configure BGPaaS in a remote compute cluster in the same manner that you would configure outside of a remote compute cluster.

For information on configuring BGPaaS in Contrail Networking, see BGP as a Service.

For additional information on remote compute in Contrail Networking, see Remote Compute.

Support to Apply Import Routing Policies to MP-BGP Routes

Starting in Contrail Networking Release 21.4.L1, you can use Contrail Networking to apply import routing policies to MP-BGP routes only. This enhancement allows routing policies to match routes from MP-BGP traffic from the MPLS backbone network without also matching routes from BGPaaS. This enhancement works by changing how a routing policy identifies routes when the protocol in the routing policy is set as BGP.

For additional information, see Routing Policy.

Remote Compute Enhancements in Contrail Command

Starting in Contrail Networking Release 21.4.L1, you can better monitor and configure BGP Routers and vRouters associated with remote compute routing clusters in the Contrail Command graphical user interface.

For more information on these enhancements, see the Monitoring and Configuring BGP Routers for Remote Compute in Contrail Command and Viewing the Virtual Router Connected to Remote Compute Clusters in Contrail Command sections in Remote Compute.

Support for Automatically Deploying Remote Compute Using RHOSP/TripleO

Starting in Contrail Networking 21.4, you can deploy remote compute automatically using RHOSP/TripleO for edge use cases.

For more information, see Remote Compute.

Graceful Restart or Long-Lived Graceful Restart Support for a EVPN Type 2 Route

Starting in Contrail Networking Release 21.4, the graceful restart or long-lived graceful restart features support the EVPN Type 2 routes to resume the sessions and relearn the routes, reducing overall network impact.

For more information, see Configuring Graceful Restart and Long-lived Graceful Restart.

UBI 8 Support for Contrail Container Images

Starting in Contrail Release 21.4, the Red Hat Universal Base Image 8 (ubi8) is used as the base for Contrail container images.

For more information, see Understanding Contrail Containers.

Upgrade Contrail Software

Starting in Contrail Networking Release 21.4, you can upgrade Red Hat OpenStack Platform (RHOSP) from RHOSP 13 or RHOSP 16.1 to RHOSP 16.2 by leveraging Red Hat Fast Forward Upgrade (FFU) procedure while simultaneously upgrading Contrail Networking from Release 1912.L4 or 2011.L3 to Release 21.4.

For more information, see Upgrading Contrail Networking Release 1912.L4 or 2011.L3 with RHOSP 13 or RHOSP 16.1 to Contrail Networking Release 21.4 with RHOSP 16.2.

Support for Hosts using Red Hat Virtualization (RHV) in Red Hat OpenStack 16 Environments

Starting in Contrail Networking Release 21.4, Contrail Networking has been enhanced to operate in Red Hat OpenStack 16 environments with hosts using Red Hat Virtualization (RHV).

For more information, see the Setting Up the Infrastructure (Contrail Networking Release 21.4 or Later) in the Using Contrail Networking with OpenStack section of the Contrail Networking Installation and Upgrade Guide.