VM loses connectivity on floating ip association when using l3_ha
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Stefan Nica |
Bug Description
I not sure if my issue is related to this bug https:/
If I create a new router in HA ( # neutron router-create --ha=True router01), everything works fine.
When I create a new router without HA flag, if I have an instance with one floating IP and then I assign a floating IP to other instance, I lose external connectivity to both instance (doesn't matter the number of instances, I lose external connectivity with all of them) until I connect to anyone by vnc and I ping to external/internet IP, and then everything works fine again.
Sorry, English is not my native language.
Ubuntu 14.04
Open vSwitch 2.3.2
Kilo 2015.1.1
root@network01:
[DEFAULT]
verbose = False
rpc_backend = rabbit
auth_strategy = keystone
core_plugin = ml2
service_plugins = router
allow_overlappi
dhcp_agents_
l3_ha = True
max_l3_
min_l2_
[matchmaker_redis]
[matchmaker_ring]
[quotas]
[agent]
root_helper = sudo /usr/bin/
[keystone_
auth_uri = http://
auth_url = http://
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = secret
[database]
[nova]
[oslo_concurrency]
lock_path = $state_path/lock
[oslo_policy]
[oslo_messaging
[oslo_messaging
[oslo_messaging
rabbit_hosts = controller01:
rabbit_userid = openstack
rabbit_password = secret
rabbit_
rabbit_
rabbit_max_retries = 0
rabbit_
rabbit_ha_queues = True
root@network01:
[DEFAULT]
verbose = True
interface_driver = neutron.
external_
router_
root@network01:
[ml2]
type_drivers = flat,vlan,gre,vxlan
tenant_
mechanism_drivers = openvswitch
[ml2_type_flat]
flat_networks = external
[ml2_type_vlan]
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
[securitygroup]
enable_
enable_ipset = True
firewall_driver = neutron.
[ovs]
local_ip = 192.168.0.101
bridge_mappings = external:br-ex
[agent]
tunnel_types = gre
root@compute01:
[DEFAULT]
verbose = True
rpc_backend = rabbit
auth_strategy = keystone
core_plugin = ml2
service_plugins = router
allow_overlappi
[matchmaker_redis]
[matchmaker_ring]
[quotas]
[agent]
root_helper = sudo /usr/bin/
[keystone_
auth_uri = http://
auth_url = http://
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = secret
[database]
[nova]
[oslo_concurrency]
lock_path = $state_path/lock
[oslo_policy]
[oslo_messaging
[oslo_messaging
[oslo_messaging
rabbit_hosts = controller01:
rabbit_userid = openstack
rabbit_password = secret
rabbit_
rabbit_
rabbit_max_retries = 0
rabbit_
rabbit_ha_queues = True
root@compute01:
[ml2]
type_drivers = flat,vlan,gre,vxlan
tenant_
mechanism_drivers = openvswitch
[ml2_type_flat]
[ml2_type_vlan]
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
[securitygroup]
enable_
enable_ipset = True
firewall_driver = neutron.
[ovs]
local_ip = 192.168.0.105
[agent]
tunnel_types = gre
tags: | added: l3-ha |
tags: | added: sts |
Changed in neutron: | |
assignee: | nobody → Stefan Nica (stefan.nica) |
Changed in neutron: | |
status: | Incomplete → In Progress |
This is different to #1389880, the underlaying mechanisms are different.
It's actually an issue in keepalived, a configuration reload triggers a DNS request trying to resolve the host name.
See: /bugzilla. redhat. com/show_ bug.cgi? id=1181592
https:/
when your controller does not have access to the host configured DNS inside the qrouter namespace, master keepalived will block waiting for the DNS response on the public interface, another keepalive will become master at that time.
A new parameter was added to the keepalive configuration, and we must now include it in neutron to avoid this issue.
A workaround is adding each of your hostnames to /etc/hosts to avoid the external resolution.