Neutron allows you to delete router_ha_interface ports, which can lead to issues
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Anton Kurbatov |
Bug Description
We ran into a problem with a customer when some external integration tries to remove all ports using the neutron API, including router prots.
It seems only the router ports with the router_ha_interface device owner are allowed to delete, all other router ports cannot be deleted directly through the API.
Here is a simple example that demonstrates the doubling of ARP responses if such a port is deleted:
[root@dev0 ~]# openstack router create r1 --ha --external-gateway public -c id
+------
| Field | Value |
+------
| id | 5d9d6fee-
+------
[root@dev0 ~]# neutron l3-agent-
neutron CLI is deprecated and will be removed in the Z cycle. Use openstack CLI instead.
+------
| id | host | admin_state_up | alive | ha_state |
+------
| 9dd0920a-
| 6fa92056-
| 8fbda128-
+------
[root@dev0 ~]# openstack port list --device-id 5d9d6fee-
+------
| ID | Device Owner | Fixed IP Addresses |
+------
| 555a9272-
| 6a196ff7-
| 7a849dcc-
| d77e624d-
+------
[root@dev0 ~]#
[root@dev0 ~]# ip netns exec snat-5d9d6fee-
...
25: ha-555a9272-c9: <BROADCAST,
link/ether fa:16:3e:7d:cf:a0 brd ff:ff:ff:ff:ff:ff
inet 169.254.192.147/18 brd 169.254.255.255 scope global ha-555a9272-c9
valid_lft forever preferred_lft forever
inet 169.254.0.189/24 scope global ha-555a9272-c9
valid_lft forever preferred_lft forever
inet6 fe80::f816:
valid_lft forever preferred_lft forever
28: qg-d77e624d-87: <BROADCAST,
link/ether fa:16:3e:a8:54:29 brd ff:ff:ff:ff:ff:ff
inet 10.136.17.172/20 scope global qg-d77e624d-87
valid_lft forever preferred_lft forever
inet6 fe80::f816:
valid_lft forever preferred_lft forever
[root@dev0 ~]#
[root@dev0 ~]# openstack port delete 555a9272-
[root@dev0 ~]# neutron l3-agent-
neutron CLI is deprecated and will be removed in the Z cycle. Use openstack CLI instead.
+------
| id | host | admin_state_up | alive | ha_state |
+------
| 6fa92056-
| 8fbda128-
+------
[root@dev0 ~]#
[root@dev0 ~]# ip netns exec snat-5d9d6fee-
28: qg-d77e624d-87: <BROADCAST,
link/ether fa:16:3e:a8:54:29 brd ff:ff:ff:ff:ff:ff
inet 10.136.17.172/20 scope global qg-d77e624d-87
valid_lft forever preferred_lft forever
inet6 fe80::f816:
valid_lft forever preferred_lft forever
[root@dev0 ~]# ssh dev2 ip netns exec snat-5d9d6fee-
28: qg-d77e624d-87: <BROADCAST,
link/ether fa:16:3e:a8:54:29 brd ff:ff:ff:ff:ff:ff
inet 10.136.17.172/20 scope global qg-d77e624d-87
valid_lft forever preferred_lft forever
inet6 fe80::f816:
valid_lft forever preferred_lft forever
[root@dev0 ~]#
[root@dev0 ~]# arping -c 1 -I eth0 10.136.17.172
ARPING 10.136.17.172 from 10.136.20.188 eth0
Unicast reply from 10.136.17.172 [FA:16:3E:A8:54:29] 1.537ms
Unicast reply from 10.136.17.172 [FA:16:3E:A8:54:29] 2.383ms
Sent 1 probes (1 broadcast(s))
Received 2 response(s)
[root@dev0 ~]#
As you can see, after deleting the HA port, we got a doubling of the ARP responses, which can lead to further problems in the roiting.
tags: | added: l3-ha |
Changed in neutron: | |
assignee: | nobody → Anton Kurbatov (akurbatov) |
importance: | Undecided → Medium |
Fix proposed to branch: master /review. opendev. org/c/openstack /neutron/ +/874931
Review: https:/