openstack floating ip cannot be accessed

Question

description

After the dvr is enabled, the two virtual machines of vip are configured with keealived. When the VIP of the private network drifts, the openstack floating ip cannot be accessed.

more detail as follows:

Two nodes, private network configuration keepalived Host1 192.168.1.2 Host2 192.168.1.3 vip192.168.1.4 Private network vip drift no problem, private network internal access vip is no problem The problem is that after the drift of the internal network's vip, the external floating ip corresponding to this vip cannot be accessed, and can be accessed before drifting. Phenomenon: Update the port of the private network that vip drifts to. The floating network can be used. What causes this problem?

Configuration reference

https://hk.saowen.com/a/4d7a3dcd044eb53ae0fc81e4d1445ba76bbb02423ff6c7b4a53a8ad59945883d

Configuration process

premise: Suppose there are already two virtual machines 10.10.10.6, 10.10.10.7, configured with keepalived, vip is 10.10.10.201 Configure the steps to support VIP and floating IP access in OpenStack:

1. Security group plus vrrp protocol 112

   neutron security-group-rule-create --protocol 112 default

2. Create vip

   neutron port-create --fixed_ip ip_address=10.10.10.201 --security-group default vrrp_net

3. Bind vip to floating ip

   neutron floatingip-create --port-id=3d7e70e9-cfcb-4aa9-95cc-60b5b6b67ec3 admin_floating_net

4. Add allowed_address_pairs to the virtual machine port to support multiple NICs for multiple NICs.

Query the port of virtual machine 1

neutron port-list | grep 10.10.10.6

Update the port of virtual machine 1

neutron port-update df22ba59-9c58-41a5-9fa3-98b09e644fe5 -- allowed_address_pairs list=true type=dict ip_address=10.10.10.201

Query the port of virtual machine 2

neutron port-list | grep 10.10.10.7

Update the port of virtual machine 2

neutron port-update 4c93d5b7-f26f-4136-a785-4db1479dbd81 -->allowed_address_pairs list=true type=dict ip_address=10.10.10.201

Answer 1

We had the same problem in OpenStack Pike. For us it seems to be vanished after upgrading to Queens. Which version are you using?

In our case the iptables rules for snat/dnat in the snat namespace on the network nodes weren't updated after a failover.

You can verify this in your installation by calling:

ip netns exec snat-<uuid of your router> iptables -t nat -L

You should see one snat and one dnat rule for your floating IP.

Some more Launchpad bugs and PRs for further reference:

• https://bugs.launchpad.net/neutron/+bug/1583694
• https://bugs.launchpad.net/neutron/+bug/1773999
• https://review.openstack.org/#/c/393886/