neutron

The dhcp port's address may be messed when the port's network has multiple subnets

Bug #1805824 reported by yangjianfeng
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
yangjianfeng

Bug Description

1、When I update one of the subnets's enable_dhcp attribute from true to false, the dhcp port still has the IP of the subnet I updated.
Reproducible Steps:
openstack network create test-dhcp
openstack subnet create --network test-dhcp --subnet-range 2.2.2.0/24 test-dhcp-subnet01
openstack subnet create --network test-dhcp --subnet-range 3.3.3.0/24 test-dhcp-subnet02
openstack subnet set test-dhcp-subnet01 --no-dhcp
Then I login the host of hold the network's dhcp namespace and check the namesapce. The result is as follows, the IP belong to test-dhcp-subnet01 is still exist.
ip netns exec qdhcp-7ba959b7-299e-4f6c-a806-b6846e1dde68 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
18: tapf258f8cc-0d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether fa:16:3e:9b:3d:7a brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.2/24 brd 2.2.2.255 scope global tapf258f8cc-0d
       valid_lft forever preferred_lft forever
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tapf258f8cc-0d
       valid_lft forever preferred_lft forever
    inet 3.3.3.3/24 brd 3.3.3.255 scope global tapf258f8cc-0d
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe9b:3d7a/64 scope link
       valid_lft forever preferred_lft forever
Next, I restart the neutron-dhcp-agent and check the namesapce again. The IP belong to test-dhcp-subnet01 is disappeared.
systemctl restart neutron-dhcp-agent
ip netns exec qdhcp-7ba959b7-299e-4f6c-a806-b6846e1dde68 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
18: tapf258f8cc-0d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether fa:16:3e:9b:3d:7a brd ff:ff:ff:ff:ff:ff
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tapf258f8cc-0d
       valid_lft forever preferred_lft forever
    inet 3.3.3.3/24 brd 3.3.3.255 scope global tapf258f8cc-0d
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe9b:3d7a/64 scope link
       valid_lft forever preferred_lft forever

2、When I update one of the subnets's enable_dhcp attribute from false to true, the DHCP port's IP belong to the subnet I updated no be set.
Reproducible Steps:
openstack network create test-dhcp
openstack subnet create --network test-dhcp --subnet-range 2.2.2.0/24 test-dhcp-subnet01
openstack subnet create --network test-dhcp --subnet-range 3.3.3.0/24 test-dhcp-subnet02 --no-dhcp
openstack subnet set test-dhcp-subnet02 --dhcp
Then I login the host of hold the network's dhcp namespace and check the namesapce. The result is as follows, the IP belong to test-dhcp-subnet02 is missing:
ip netns exec qdhcp-08621ab0-e012-459c-9a1c-a8f24b56f881 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
19: tape7959c7d-39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether fa:16:3e:a8:4d:fe brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.2/24 brd 2.2.2.255 scope global tape7959c7d-39
       valid_lft forever preferred_lft forever
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tape7959c7d-39
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fea8:4dfe/64 scope link
       valid_lft forever preferred_lft forever
Then I restart the neutron-dhcp-agent, The result becomes correct.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
19: tape7959c7d-39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether fa:16:3e:a8:4d:fe brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.2/24 brd 2.2.2.255 scope global tape7959c7d-39
       valid_lft forever preferred_lft forever
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tape7959c7d-39
       valid_lft forever preferred_lft forever
    inet 3.3.3.2/24 brd 3.3.3.255 scope global tape7959c7d-39
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fea8:4dfe/64 scope link
       valid_lft forever preferred_lft forever

See original description
yangjianfeng (yangjianfeng)
description: updated
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/620900

Changed in neutron:
assignee: nobody → yangjianfeng (yangjianfeng)
status: New → In Progress
Miguel Lavalle (minsel)
Changed in neutron:
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/620900
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=9aa7af82210f1ffb6274399648962b65162e17d1
Submitter: Zuul
Branch: master

commit 9aa7af82210f1ffb6274399648962b65162e17d1
Author: Yang JianFeng <email address hidden>
Date: Thu Nov 29 20:18:31 2018 +0800

    Fix the bug about DHCP port whose network has multiple subnets.

    When a subnet's enable_dhcp attribute is updated, we must restart
    dhcp device. So,when we decide whether 'restart' or
    'reload_allocations' in refresh_dhcp_helper function we only compare
    the cidr of subnets which enabled dhcp.

    The previous logic only calls 'restart' when deleting or adding a
    subnet. This may cause the dhcp port not updated when the subnet's
    enable_dhcp is updated to True.

    Change-Id: Ic547946ac786c5fab82b4ee7078bf86483f51eb5
    Closes-Bug: #1805824

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

Fix proposed to branch: stable/rocky
Review: https://review.openstack.org/625151

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

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/625152

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

Reviewed: https://review.openstack.org/625151
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fea4365500ae509f051ccf2a6ac11adec071345b
Submitter: Zuul
Branch: stable/rocky

commit fea4365500ae509f051ccf2a6ac11adec071345b
Author: Yang JianFeng <email address hidden>
Date: Thu Nov 29 20:18:31 2018 +0800

    Fix the bug about DHCP port whose network has multiple subnets.

    When a subnet's enable_dhcp attribute is updated, we must restart
    dhcp device. So,when we decide whether 'restart' or
    'reload_allocations' in refresh_dhcp_helper function we only compare
    the cidr of subnets which enabled dhcp.

    The previous logic only calls 'restart' when deleting or adding a
    subnet. This may cause the dhcp port not updated when the subnet's
    enable_dhcp is updated to True.

    Change-Id: Ic547946ac786c5fab82b4ee7078bf86483f51eb5
    Closes-Bug: #1805824
    (cherry picked from commit 9aa7af82210f1ffb6274399648962b65162e17d1)

tags: added: in-stable-rocky
tags: added: in-stable-queens
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/queens)

Reviewed: https://review.openstack.org/625152
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ce2ddcbf3f0cddeb1025f4aab224d78df4554630
Submitter: Zuul
Branch: stable/queens

commit ce2ddcbf3f0cddeb1025f4aab224d78df4554630
Author: Yang JianFeng <email address hidden>
Date: Thu Nov 29 20:18:31 2018 +0800

    Fix the bug about DHCP port whose network has multiple subnets.

    When a subnet's enable_dhcp attribute is updated, we must restart
    dhcp device. So,when we decide whether 'restart' or
    'reload_allocations' in refresh_dhcp_helper function we only compare
    the cidr of subnets which enabled dhcp.

    The previous logic only calls 'restart' when deleting or adding a
    subnet. This may cause the dhcp port not updated when the subnet's
    enable_dhcp is updated to True.

    Change-Id: Ic547946ac786c5fab82b4ee7078bf86483f51eb5
    Closes-Bug: #1805824
    (cherry picked from commit 9aa7af82210f1ffb6274399648962b65162e17d1)

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

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/625387

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 14.0.0.0b1

This issue was fixed in the openstack/neutron 14.0.0.0b1 development milestone.

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

Reviewed: https://review.openstack.org/625387
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=cc7e3e92feac49112f6ab594895f1a6ad3f57eeb
Submitter: Zuul
Branch: stable/pike

commit cc7e3e92feac49112f6ab594895f1a6ad3f57eeb
Author: Yang JianFeng <email address hidden>
Date: Thu Nov 29 20:18:31 2018 +0800

    Fix the bug about DHCP port whose network has multiple subnets.

    When a subnet's enable_dhcp attribute is updated, we must restart
    dhcp device. So,when we decide whether 'restart' or
    'reload_allocations' in refresh_dhcp_helper function we only compare
    the cidr of subnets which enabled dhcp.

    The previous logic only calls 'restart' when deleting or adding a
    subnet. This may cause the dhcp port not updated when the subnet's
    enable_dhcp is updated to True.

    Change-Id: Ic547946ac786c5fab82b4ee7078bf86483f51eb5
    Closes-Bug: #1805824
    (cherry picked from commit 9aa7af82210f1ffb6274399648962b65162e17d1)

tags: added: in-stable-pike
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 11.0.7

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 13.0.3

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 12.0.6

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

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

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

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