Incorrect Floating IP behavior in dual stack or ipv6 only network

Bug #1323766 reported by Baodong (Robert) Li
52
This bug affects 6 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Dustin Lundquist
Kilo
New
Undecided
Unassigned

Bug Description

investigation on the floatingip API revealed a few issues:
  -- if the external network is associated with multiple subnets, one IP address from each of the subnets is allocated. But the ip address used for the floating ip is picked up randomly. For example, a network could have both an ipv6 and an ipv4 subnet. In my tests, for one of such network, it picked up the ipv4 address; for the other, it picked up the ipv6 address.
  -- given that one IP is allocated from each subnet, addresses not used for floating ip is wasted.
  -- Most likely, ipv6 floating ip (with the same mechanism as ipv4) won't be supported. But the API allows ipv6 addresses to be used as floating ip.
  -- it allows an IPv4 floating ip to be associated with a port's ipv6 addresses, and vice versa.

In general, the behavior/semantics involved in the floating IP API needs to be looked at in the context of dual stack or ipv6 only network.

tags: added: ipv6
Aaron Rosen (arosen)
Changed in neutron:
status: New → Confirmed
status: Confirmed → New
tags: added: l3-ipam-dhcp
Changed in neutron:
assignee: nobody → Baodong (Robert) Li (baoli)
Changed in neutron:
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/131145

Changed in neutron:
assignee: Baodong (Robert) Li (baoli) → Bradley Jones (bradjones)
status: New → In Progress
Kyle Mestery (mestery)
Changed in neutron:
milestone: none → kilo-1
Revision history for this message
Carl Baldwin (carl-baldwin) wrote :

Are you certain that one IP is allocated for each subnet? Or, is it one IP address per IP version (e.g. one IPv4 and one IPv6)? My testing with multiple IPv4 subnets showed that only one IP address is allocated for IPv4 despite multiple subnets but I was not testing with any IPv6 networks at the time.

I just want to clarify, I think that it is one address per IP version.

Revision history for this message
Carl Baldwin (carl-baldwin) wrote :

I think we should probably only allocate one address per floating ip in the long run. Could we stop wasting an IPv6 allocation for floating IPs? If IPv6 floating IPs is ever supported, we could add the IP version to the floating IP create API and default it to IPv4.

Revision history for this message
Carl Baldwin (carl-baldwin) wrote :

I'm not certain if we will support IPv6 floating IPs or not but I have heard some interest. So, I'm not sure it is completely off the table, is it? Asaik, we currently don't have a good way to manage a shared and globally routable IP space for IPv6 like we do for IPv4 using floating IPs. Do we? We may end up doing it by allocating routable prefixes (/64s) like we do IPv4 floating IPs. I'm just thinking out loud.

Kyle Mestery (mestery)
Changed in neutron:
milestone: kilo-1 → kilo-2
Kyle Mestery (mestery)
Changed in neutron:
milestone: kilo-2 → kilo-3
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/131145
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Kyle Mestery (mestery)
Changed in neutron:
milestone: kilo-3 → none
Changed in neutron:
assignee: Bradley Jones (bradjones) → Dustin Lundquist (dlundquist)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/198908
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4cdc71e7d0e5220a5f12ee2dfea1ff3db045c041
Submitter: Jenkins
Branch: master

commit 4cdc71e7d0e5220a5f12ee2dfea1ff3db045c041
Author: Dustin Lundquist <email address hidden>
Date: Mon Jul 6 13:53:46 2015 -0700

    Ensure floating IPs only use IPv4 addresses

    Description:
    Presently Neutron doesn't validate the address family of floating IP
    addresses or the internal addresses they are associated with. It merely
    associates the first IP of the floating IP's port with the first IP of
    the internal port, unless a specified fixed IP is specified. This can
    lead to incorrect or poorly defined behavior when IPv6 is present.

    The existing L3 agent implementation only manages IPv4 NAT rules. While
    IPv6 NAT and NAT protocol translation are possible, the existing
    implementation does not support these configurations.

    Presently a floating IP can be created on an IPv6 only external network
    or associated with an IPv6 fixed IP, but the L3 agent is unable to bind
    these configurations.

    Implementation:
    When creating and updating a floating IP, only consider IPv4 addresses
    on both the floating IPs port and the internal port he floating IP is
    associated with. Additionally disallow creating floating IPs on networks
    without any IPv4 subnets, since these floating IPs could not be
    allocated an IPv4 address.

    DocImpact
    APIImpact

    Co-Authored-By: Bradley Jones <email address hidden>
    Change-Id: I79b28a304b38ecdafc17eddc41213df1c24ec202
    Related-Bug: #1437855
    Closes-Bug: #1323766
    Closes-Bug: #1469322

Changed in neutron:
status: In Progress → Fix Committed
Changed in neutron:
milestone: none → liberty-2
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (feature/pecan)

Fix proposed to branch: feature/pecan
Review: https://review.openstack.org/207903

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (feature/pecan)
Download full text (70.7 KiB)

Reviewed: https://review.openstack.org/207903
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9badcd249dab2d3330f0cd608496b59c9f44499a
Submitter: Jenkins
Branch: feature/pecan

commit 991ea00e6c115343eabecc62e86072175823f81f
Author: Moshe Levi <email address hidden>
Date: Thu Jul 30 12:04:15 2015 +0300

    SR-IOV: Fix SR-IOV agent to run ip link commands as root

    Commit https://review.openstack.org/#/c/155523/
    remove the remaining root_helper args, but didn't
    update the SR-IOV agent to execute them as root.

    This patch updates the agent to execute ip link commands
    as root and pass options argument as a list in the
    self._as_root method.

    Closes-Bug: #1479694
    Change-Id: I53cafd61845a69fae3a759fb7526950d655ffa20

commit 5b3bacedf6c014815bef03c2e821b5eb8ef92dcb
Author: Saksham Varma <email address hidden>
Date: Thu Jul 23 22:46:23 2015 -0700

    Moved out cisco n1kv mech driver and db models

    Moving out Cisco N1Kv database models and the mech driver
    to the openstack/networking-cisco repo as part of the second
    phase vendor-core decomposition

    Partial-Bug: #1479123
    Partial-implements: blueprint core-vendor-decomposition

    Change-Id: I65a704b238d8cbe2951a6912fa4f1e8518c6f412

commit 65ac8cd0a80548e115b8ec1d4cfd47a94422fddf
Author: OpenStack Proposal Bot <email address hidden>
Date: Wed Jul 29 20:44:01 2015 +0000

    Updated from global requirements

    Change-Id: I3a884a73d51df0f93b5cc88b3e3250d81bb1f455

commit f0e8356d04d04600c072a1c0f0bdf274ff19ab8c
Author: sridhargaddam <email address hidden>
Date: Mon Jul 27 03:46:48 2015 +0000

    Update dhcp agent cache for network:dhcp ports

    When a network with a dhcp_enabled subnet is scheduled on a dhcp
    agent, dhcp driver creates the network:dhcp port for the subnet.
    However, the port info is not updated in dhcp agents internal cache.
    Subsequently if the user deletes the network:dhcp port, the port is
    properly deleted on the server side (i.e., in the database) and when
    the port_delete_end notification is sent to the dhcp agent, it simply
    ignores it as the port entry would be missing in the cache. This patch
    fixes this issue by updating the dhcp agents cache when dhcp driver
    creates the network:dhcp port for the subnets.

    Closes-Bug: #1478426
    Change-Id: I69f5834dd964a4320c606c4e0aa2cdba70416943

commit cb60d0bb4e0cc0cba68f59fdf5f4e89d6ec52950
Author: changzhi <email address hidden>
Date: Thu Jul 16 10:14:16 2015 +0800

    Keep dns nameserver order consistency

    Currently, there is no dns servers prioritization for subnets
    for Neutron.

    Generally speaking, it is useful to keep the order of dns
    nameservers consistent. Add a new column named 'order' in table
    'dnsnameservers' and add nameserver into DB one by one.

    Closes-Bug: #1218629
    Implements: blueprint keep-dns-nameserver-orderconsistency
    Change-Id: Id937aea411397d39370368a4eb45be26c4eefa9e

commit b39e1469e824bc8bc79e1ecafa98825a94811c0b
Author: Salvatore Orlando <email address hidden>
Date: Tue Jun 23 04:54:2...

tags: added: in-feature-pecan
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Bradley Jones (<email address hidden>) on branch: master
Review: https://review.openstack.org/131145
Reason: Patch no longer needed

Thierry Carrez (ttx)
Changed in neutron:
milestone: liberty-2 → 7.0.0
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/kilo)

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/267891

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/kilo)

Reviewed: https://review.openstack.org/267891
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4858cd7cb97354ae54f8e7d47aeaaddad714c9dd
Submitter: Jenkins
Branch: stable/kilo

commit 4858cd7cb97354ae54f8e7d47aeaaddad714c9dd
Author: Dustin Lundquist <email address hidden>
Date: Mon Jul 6 13:53:46 2015 -0700

    Ensure floating IPs only use IPv4 addresses

    Description:
    Presently Neutron doesn't validate the address family of floating IP
    addresses or the internal addresses they are associated with. It merely
    associates the first IP of the floating IP's port with the first IP of
    the internal port, unless a specified fixed IP is specified. This can
    lead to incorrect or poorly defined behavior when IPv6 is present.

    The existing L3 agent implementation only manages IPv4 NAT rules. While
    IPv6 NAT and NAT protocol translation are possible, the existing
    implementation does not support these configurations.

    Presently a floating IP can be created on an IPv6 only external network
    or associated with an IPv6 fixed IP, but the L3 agent is unable to bind
    these configurations.

    Implementation:
    When creating and updating a floating IP, only consider IPv4 addresses
    on both the floating IPs port and the internal port he floating IP is
    associated with. Additionally disallow creating floating IPs on networks
    without any IPv4 subnets, since these floating IPs could not be
    allocated an IPv4 address.

    DocImpact
    APIImpact

    Co-Authored-By: Bradley Jones <email address hidden>
    Change-Id: I79b28a304b38ecdafc17eddc41213df1c24ec202
    Related-Bug: #1437855
    Closes-Bug: #1323766
    Closes-Bug: #1469322
    (cherry picked from commit 4cdc71e7d0e5220a5f12ee2dfea1ff3db045c041)

tags: added: in-stable-kilo
Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/neutron 2015.1.4

This issue was fixed in the openstack/neutron 2015.1.4 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

This issue was fixed in the openstack/neutron 2015.1.4 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.