I not sure if my issue is related to this bug https://bugs.launchpad.net/neutron/+bug/1389880, it's new one or it's a misconfiguration, but I have the same symptoms.
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:/home/administrator# cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^#
[DEFAULT]
verbose = False
rpc_backend = rabbit
auth_strategy = keystone
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
dhcp_agents_per_network = 2
l3_ha = True
max_l3_agents_per_router = 2
min_l2_agents_per_router = 2
[matchmaker_redis]
[matchmaker_ring]
[quotas]
[agent]
root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[keystone_authtoken]
auth_uri = http://10.8.11.120:5000
auth_url = http://10.8.11.120:35357
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_amqp]
[oslo_messaging_qpid]
[oslo_messaging_rabbit]
rabbit_hosts = controller01:5672,controller02:5672
rabbit_userid = openstack
rabbit_password = secret
rabbit_retry_interval = 1
rabbit_retry_backoff = 2
rabbit_max_retries = 0
rabbit_durable_queues = True
rabbit_ha_queues = True
root@network01:/home/administrator# cat /etc/neutron/l3_agent.ini | grep -v ^$ | grep -v ^#
[DEFAULT]
verbose = True
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
external_network_bridge =
router_delete_namespaces = True
root@network01:/home/administrator# cat /etc/neutron/plugins/ml2/ml2_conf.ini | grep -v ^$ | grep -v ^#
[ml2]
type_drivers = flat,vlan,gre,vxlan
tenant_network_types = gre
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_security_group = True
enable_ipset = True
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[ovs]
local_ip = 192.168.0.101
bridge_mappings = external:br-ex
[agent]
tunnel_types = gre
root@compute01:/home/ubuntu# cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^#
[DEFAULT]
verbose = True
rpc_backend = rabbit
auth_strategy = keystone
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
[matchmaker_redis]
[matchmaker_ring]
[quotas]
[agent]
root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf
[keystone_authtoken]
auth_uri = http://10.8.11.120:5000
auth_url = http://10.8.11.120:35357
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_amqp]
[oslo_messaging_qpid]
[oslo_messaging_rabbit]
rabbit_hosts = controller01:5672,controller02:5672
rabbit_userid = openstack
rabbit_password = secret
rabbit_retry_interval = 1
rabbit_retry_backoff = 2
rabbit_max_retries = 0
rabbit_durable_queues = True
rabbit_ha_queues = True
root@compute01:/home/ubuntu# cat /etc/neutron/plugins/ml2/ml2_conf.ini | grep -v ^$ | grep -v ^#
[ml2]
type_drivers = flat,vlan,gre,vxlan
tenant_network_types = gre
mechanism_drivers = openvswitch
[ml2_type_flat]
[ml2_type_vlan]
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
[securitygroup]
enable_security_group = True
enable_ipset = True
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
[ovs]
local_ip = 192.168.0.105
[agent]
tunnel_types = gre
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:
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.