OpenStack Neutron IPv6 support in OpenContrail SDN

Jakub Pavlik, Marek Celoud - March 23, 2016 -
As private cloud (primary based on OpenStack) deployers and integrators lots of customer ask as about support of IPv6. Most of our deployments run on OpenContrail SDN&NFV. Reasons are described in our previous blogs ( . OpenContrail SDN supports IPv6 for quite long, but there is not so many real tests. Therefore we decided to share procedure how we configured and used IPv6 in OpenStack.

This short blog desribes support of IPv6 in OpenStack using Neutron plugin for SDN/NFV – OpenContrail.

With cloud deployments there is significant growth of need for public IP addresses. These deployments are facing problems due to lack of IPv4 addresses. One of the solutions is to migrate to public IPv6.

We start with capability of IPv6 for internal communication between virtual machines within same virtal network and across different virtual network. Then we show how to expand IPv6 public addresses to external world. In our case we use Juniper MX routers as cloud gateway.

Creating IPv6 network

We need to consider few things when creating IPv6 virtual network. First one is adding also IPv4 subnet, because without IPv4 address instance can not connect to nova metadata api. Cloud images are built to use cloud-init to connect to API on address. So if you create network without IPv4 subnet, you will not receive metadata to your instance. Second consideration is whether to you want to go to internet with your IPv6 capable instances. There is currently problem with IPv6 floating IP pool, so if you want to expand to external world, you need to boot to network with associated route target.

We first create private IPv6 network for demonstation.


When the network is created we can boot instances. We will boot 2 of them to demonstrate functional communication. You will probably need to modify network interface configuration, because there is not enabled dhcp for IPv6. For nonpreemptive recieve you can use:

#dhclient -6

As you can see, you have both IPv4 and IPv6 address associated with interface of instance.


Before testing communication, we need to modify security groups to enable traffic. For testing purposes we will enable everything.


We choose ubuntu-ipv6-1 from instance list and try to ping instance ubuntu-ipv6-2 with fd00::3 IPv6 address.


As you can see, we are now able to ping other instance.


This capability is nice, but not very useful without connecting to external world. We will create route with associated route target to expand routes to Juniper MX routers via BGP. In the picture below is sample architecture. There is one VRF CLOUD-INET created on each of MX routers. The route target associated with this VRF matches route target added to virtual network in Contrail. In the picture is demonstrated both IPv4 and IPv6 addresses propagated to same VRF. There is also INET virtual-router, that is connected to VRF via lt tunnel interfaces running ospf and ospf3. From this virtual-router is aggregated default route ::/0 from all internet routes from upstream EBGP.

There are few things to configure on MX routers to enable IPv6 traffic from cloud. First is enabling ipv6 tunneling through mpls tunnels.

protocols {
    mpls {
        interface all;

It is also good practice to filter what routes you export and import to and from cloud. We only need default route present in cloud. And we also want to filter only IPv6 addresses to be imported from Contrail, because of IPv4 pool created with IPv6 virtual network.

policy-statement CLOUD-INET-EXPORT {
    term FROM-MX-IPV6 {
        from {
            protocol ospf3;
            route-filter ::/0 exact;
        then {
            community add CLOUD-INET-EXPORT-COMMUNITY;
    term LAST {
        then reject;
policy-statement CLOUD-INET-IMPORT {
        from {
            family inet6;
            community CLOUD-INET-IMPORT-COMMUNITY;
            route-filter 2a06:f6c0::/64 orlonger;
        then accept;
    term LAST {
        then reject;
community CLOUD-INET-EXPORT-COMMUNITY members target:64513:10;
community CLOUD-INET-IMPORT-COMMUNITY members target:64513:10;

So now we create network 2a06:f6c0::/64 and we associate route target 64513:10 to this network. We can also make it shared so all tenants can boot in this network. Once we create instance to this network, there is already routing information in MX routing table.

# run show route table CLOUD-INET.inet6.0

CLOUD-INET.inet6.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/0               *[OSPF3/150] 20:37:13, metric 0, tag 0
                    > to fe80::6687:8800:0:2f7 via lt-0/0/0.3
2a06:f6c0::3/128   *[BGP/170] 00:00:15, localpref 100, from
                      AS path: ?, validation-state: unverified
                    > via gr-0/0/0.32789, Push 1046
                    [BGP/170] 00:00:15, localpref 100, from
                      AS path: ?, validation-state: unverified
                    > via gr-0/0/0.32789, Push 1046

We can also verify that default route is propagated by ispecting routing tables in Contrail.


When we verify that instance have public IPv6 address, we can try to access internet.


ping google


We proved that OpenContrail SDN solution is fully IPv6 capable with cloud platform OpenStack for private and public communication and communicate directly with edge routers as Juniper MX, Cisco ASR, etc.

Jakub Pavlik & Marek Celoud

From Virtualization to Containerization
Learn how to move from monolithic to microservices in this free eBook
Download Now
Radio Cloud Native – Week of May 11th, 2022

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news. This week they discussed: Docker Extensions Artificial Intelligence shows signs that it's reaching the common person Google Cloud TPU VMs reach general availability Google buys MobileX, folds into Google Cloud NIST changes Palantir is back, and it's got a Blanket Purchase Agreement at the Department of Health and Human …

Radio Cloud Native – Week of May 11th, 2022
Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!

In the last several weeks we have released two updates to Mirantis Container Cloud - versions 2.16 and 2.17, which bring a number of important changes and enhancements. These are focused on both keeping key components up to date to provide the latest functionality and security fixes, and also delivering new functionalities for our customers to take advantage of in …

Where do Ubuntu 20.04, OpenSearch, Tungsten Fabric, and more all come together? In the latest Mirantis Container Cloud releases!
Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]

Cloud environments & Kubernetes are becoming more and more expensive to operate and manage. In this demo-rich workshop, Mirantis and Kubecost demonstrate how to deploy Kubecost as a Helm chart on top of Mirantis Kubernetes Engine. Lens users will be able to visualize their Kubernetes spend directly in the Lens desktop application, allowing users to view spend and costs efficiently …

Monitoring Kubernetes costs using Kubecost and Mirantis Kubernetes Engine [Transcript]
Manage your cloud-native container environment with Mirantis Container Cloud

Wednesday, January 5 at 10:00 am PST
Istio in the Enterprise: Security & Scale Out Challenges for Microservices in k8s

Presented with Tetrate
Mirantis Webstore
Purchase Kubernetes support