Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Troubleshooting the Floating IP Address Pool in Contrail

This document provides troubleshooting methods to use when you have errors with the floating IP address pool when using Contrail.

Example Cluster

Examples in this document refer to a virtual cluster that is set up as follows:

The following virtual networks are used in the examples in this document:

Public virtual network:

  • Virtual network name: public_vn

  • Public addresses range: to

  • Route Target: 64512:10003

  • Floating IP pool name: public_pool

Private virtual network:

  • Virtual network name: vn1

  • Subnet:


A virtual machine is created in the virtual network VN1 with the name VN1_VM1 and with the IP address A floating IP address of is associated to the VN1_VM1 instance.

An MX80 router is configured as a gateway to peer with control nodes nodec7 and nodec8.

Example: MX80 Configuration for the Gateway

The following is the Junos OS configuration for the MX80 gateway. The route is the route to the external world.

Ping the Floating IP from the Public Network

From the public network, ping the floating IP

Troubleshooting Details

The following sections show details of ways to get related information, view, troubleshoot, and validate floating IP addresses in Contrail Networking.

Get the UUID of the Virtual Network

Use the following to get the universal unique identifier (UUID) of the virtual network.

View the Floating IP Object in the API Server

Use the following to view the floating IP pool information in the API server. API server requests can be made on http port 8082.

The Contrail API servers have the virtual-network public_vn object that contains floating IP pool information. Use the following to view the floating-ip-pools object information.

curl -s -X GET -H "X-Auth-Token: $(openstack token issue | grep '| id' | awk '{print $4}')" http://<API-Server_IP>:8082/virtual-network/<UUID_of_VN>


View floating-ips in floating-ip-pools in the API Server

Once you have located the floating-ip-pools object, use the following to review its floating-ips object.

The floating-ips object should display the floating IP that is shown in the Contrail UI. The floating IP should have a reference to the virtual machine interface (VMI) object that is bound to the floating IP.


Check Floating IP Objects in the Virtual Machine Interface

Use the following to retrieve the virtual machine interface of the virtual machine from either the quantum port-list command or from the Contrail UI. Then get the virtual machine interface identifier and check its floating IP object associations.

  • Using openstack portlist to get the virtual machine interface:
  • Using Contrail UI to get the virtual machine interface:

Checking Floating IP Objects on the Virtual Machine Interface

Once you have obtained the virtual machine interface identifier, check the floating-ip objects that are associated with the virtual machine interface.

View the BGP Peer Status on the Control Node

Use the Contrail UI or the control node http introspect on port 8083 to view the BGP peer status. In the following example, the control nodes are nodec7 and nodec8.

Ensure that the BGP peering state is displayed as Established for the control nodes and the gateway MX.


  • Using the Contrail UI:

  • Using the control-node Introspect:



Querying Routes in the Public Virtual Network

On each control-node, a query on the routes in the public_vn lists the routes that are pushed by the MX gateway, which in the following example are and

In the following results, the floating IP route of is installed by the compute node (nodec10) that hosts that virtual machine.


  • Using the Contrail UI:

  • Using the http Introspect:

    Following is the format for using an introspect query.

    http://<nodename/ip>:8083/Snh_ShowRouteReq?x=<RoutingInstance of public VN>.inet.0



View Corresponding BGP L3VPN Routes

Use the Contrail UI or the http introspect to view the public route’s corresponding BGP L3VPN routes, as in the following example.


  • Using the Contrail UI:

  • Using the control-node Introspect:



Verification from the MX80 Gateway

This section provides options for verifying floating IP pools from the MX80 gateway.

Verify BGP Sessions are Established

Use the following commands from the gateway to verify that BGP sessions are established with the control nodes nodec7 and nodec8:

Show Routes Learned from Control Nodes

From the MX80, use show route to display the routes for the virtual machine that are learned from both control-nodes.

In the following example, the routes learned are and, pointing to a dynamic GRE tunnel next hop with a label of 16 (of the virtual machine).

Viewing the Compute Node Vnsw Agent

The compute node introspect can be accessed from port 8085. In the following examples, the compute nodes are nodec9 and nodec10.

View Routing Instance Next Hops

On the routing instance of VN1, the routes and should have the next hop pointing to the MX gateway (


  1. Using the Contrail UI:

Using the Unicast Route Table Index to View Next Hops

Alternatively, from the agent introspect, you can view the next hops at the unicast route table.

First, use the following to get the unicast route table index (ucindex ) for the routing instance default-domain:admin:public_vn:public_vn.



  1. In the following example, the unicast route table index is 2.

Next, perform a route request query on ucindex 2, as shown in the following. The tunnel detail indicates the source and destination endpoints of the tunnel and the MPLS label 16 (the label of the virtual machine).

The query should also show a route for with an interface next hop of tap-interface. http://nodec10:8085/Snh_Inet4UcRouteReq?x=2

A ping from the MX gateway to the virtual machine’s floating IP in the public routing-instance should work.

Advanced Troubleshooting

If you still have reachability problems after performing all of the tests in this article, for example, a ping between the virtual machine and the MX IP or to public addresses is failing, try the following:

  • Validate that all the required Contrail processes are running by using the contrail-status command on all of the nodes.

  • On the compute node where the virtual machine is present (nodec10 in this example), perform a tcpdump on the tap interface (tcpdump –ni tapcdca35ce-84). The output should show the incoming packets from the virtual machine.

  • Check to see if any packet drops occur in the kernel vrouter module:


    In the output, scroll down to find any drops. Note: You can ignore any ds_invalid_arp increments.

  • On the physical interface where packets transmit onto the compute-node, perform a tcpdump matching the host IP of the MX to show the UDP and GRE encapsulated packets, as in the following.

  • On the MX gateway, use the following to inspect the GRE tunnel rx/tx (received/transmitted) packet count:

  • Look for any packet drops in the FPC, as in the following:

    show pfe statistics traffic fpc <id>

  • Also inspect the dynamic tunnels, using the following:

    show dynamic-tunnels database