Allowed_address_pair fixed_ip configured with FloatingIP after getting associated with a VM port does not work with DVR routers

Bug #1569918 reported by Swaminathan Vasudevan
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
High
Brian Haley

Bug Description

Allowed_address_pair fixed_ip when configured with FloatingIP after the port is associated with the VM port is not reachable from DVR router.

The current code only supports adding in the proper ARP update and port host binding inheritence for the Allowed_address_pair port only if the port has a FloatingIP configured before it is associated with a VM port.

When the floatingIP is added later, it fails.

How to reproduce.

1. Create networks
2. Create vrrp-net.
3. Create vrrp-subnet.
4. Create a DVR router.
5. Attach the vrrp-subnet to the router.
6. Create a VM on the vrrp-subnet
7. Create a VRRP port.
8. Attach the VRRP port with the VM.
9. Now assign a FloatingIP to the VRRP port.
10. Now check the ARP table entry in the router_namespace and also the VRRP port details. The VRRP port is still unbound and so the DVR cannot handle unbound ports.

Revision history for this message
Brandon Logan (brandon-logan) wrote :

Octavia's default implementation is affected by this because it makes use of allowed address pairs to deliver HA load balancers.

Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Brandon Logan (brandon-logan) wrote :

Previous bug report that appears to not have fixed the issue in full

https://bugs.launchpad.net/neutron/+bug/1445255

Changed in neutron:
assignee: nobody → Swaminathan Vasudevan (swaminathan-vasudevan)
status: Confirmed → In Progress
Revision history for this message
Swaminathan Vasudevan (swaminathan-vasudevan) wrote :

For some reason the patch is not showing up here.

https://review.openstack.org/#/c/304905/

Revision history for this message
Swaminathan Vasudevan (swaminathan-vasudevan) wrote :

This patch should fix the above mentioned issue when fip is delayed.

Revision history for this message
denghui huang (huangdenghui) wrote :

I also have a question about fix of bug 1445255, what if VRRP IP address float between two fixed port?

Changed in neutron:
assignee: Swaminathan Vasudevan (swaminathan-vasudevan) → Brian Haley (brian-haley)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/304905
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3a5315ef8dbc6265ad2c47eebc1e2c42722a7cb4
Submitter: Jenkins
Branch: master

commit 3a5315ef8dbc6265ad2c47eebc1e2c42722a7cb4
Author: Swaminathan Vasudevan <email address hidden>
Date: Tue Apr 12 16:06:41 2016 -0700

    DVR: Fix allowed_address_pair port binding with delayed fip

    Today when allowed_address_pairs are configured on a dvr
    service port and if a floatingip is associated with the
    allowed_address_pair port, we inherit the dvr service port's
    host and the device_owner to which the port is associated.

    But when the floatingip is created on the allowed_address_pair
    port after the port is associated with a dvr service port, then
    we apply the right port host binding and the arp_update.

    This patch address the issue, by checking for the host binding
    when there is a new floatingip configured. If host binding is
    missing and if the port happens to be an allowed_address_pair
    port, then it checks for the associated service port and if there
    is a single valid and active service port, then it inherits the
    host binding and device owner from the dvr service port and also
    applies the right arp entry. If there is are more than one
    active ports, then it returns.

    Closes-Bug: #1569918
    Change-Id: I80a299d3f99113f77d2e728c3d9e000d01dacebd

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/mitaka)

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/328570

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

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/328578

tags: added: neutron-proactive-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/mitaka)

Reviewed: https://review.openstack.org/328570
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=85ac60cc8faced17456231ee64aa0dfb4fb92688
Submitter: Jenkins
Branch: stable/mitaka

commit 85ac60cc8faced17456231ee64aa0dfb4fb92688
Author: Swaminathan Vasudevan <email address hidden>
Date: Tue Apr 12 16:06:41 2016 -0700

    DVR: Fix allowed_address_pair port binding with delayed fip

    Today when allowed_address_pairs are configured on a dvr
    service port and if a floatingip is associated with the
    allowed_address_pair port, we inherit the dvr service port's
    host and the device_owner to which the port is associated.

    But when the floatingip is created on the allowed_address_pair
    port after the port is associated with a dvr service port, then
    we apply the right port host binding and the arp_update.

    This patch address the issue, by checking for the host binding
    when there is a new floatingip configured. If host binding is
    missing and if the port happens to be an allowed_address_pair
    port, then it checks for the associated service port and if there
    is a single valid and active service port, then it inherits the
    host binding and device owner from the dvr service port and also
    applies the right arp entry. If there is are more than one
    active ports, then it returns.

    Closes-Bug: #1569918
    Change-Id: I80a299d3f99113f77d2e728c3d9e000d01dacebd
    (cherry picked from commit 3a5315ef8dbc6265ad2c47eebc1e2c42722a7cb4)

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

This issue was fixed in the openstack/neutron 9.0.0.0b2 development milestone.

Revision history for this message
Ihar Hrachyshka (ihar-hrachyshka) wrote :

Affects Octavia, raising to High.

Changed in neutron:
importance: Medium → High
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/liberty)

Reviewed: https://review.openstack.org/328578
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3c865148704dbb0c2b93df72dd9787a912fa2e9d
Submitter: Jenkins
Branch: stable/liberty

commit 3c865148704dbb0c2b93df72dd9787a912fa2e9d
Author: Swaminathan Vasudevan <email address hidden>
Date: Tue Apr 12 16:06:41 2016 -0700

    DVR: Fix allowed_address_pair port binding with delayed fip

    Today when allowed_address_pairs are configured on a dvr
    service port and if a floatingip is associated with the
    allowed_address_pair port, we inherit the dvr service port's
    host and the device_owner to which the port is associated.

    But when the floatingip is created on the allowed_address_pair
    port after the port is associated with a dvr service port, then
    we apply the right port host binding and the arp_update.

    This patch address the issue, by checking for the host binding
    when there is a new floatingip configured. If host binding is
    missing and if the port happens to be an allowed_address_pair
    port, then it checks for the associated service port and if there
    is a single valid and active service port, then it inherits the
    host binding and device owner from the dvr service port and also
    applies the right arp entry. If there is are more than one
    active ports, then it returns.

    Closes-Bug: #1569918
    (cherry picked from commit 3a5315ef8dbc6265ad2c47eebc1e2c42722a7cb4)

    Conflicts:
     neutron/db/l3_dvr_db.py
    Change-Id: I80a299d3f99113f77d2e728c3d9e000d01dacebd

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

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

Revision history for this message
Doug Hellmann (doug-hellmann) wrote : Fix included in openstack/neutron 8.2.0

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

tags: removed: neutron-proactive-backport-potential
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.