[Openstack-operators] Neutron not adding iptables rules for metadata agent
Radu Popescu | eMAG, Technology
radu.popescu at emag.ro
Mon Jun 18 10:19:04 UTC 2018
Hi,
We're using Openstack Ocata, deployed using Openstack Ansible v15.1.7. Neutron server is v10.0.3.
I can see enable_isolated_metadata and enable_metadata_network only used for isolated networks that don't have a router which is not our case.
Also, I checked all namespaces on all our novas and only affected 6 out of 66 ..and only 1 namespace / nova. Seems like isolated case that doesn't happen very often.
Can it be RabbitMQ? I'm not sure where to check.
Thanks,
Radu
On Fri, 2018-06-15 at 17:11 +0200, Saverio Proto wrote:
Hello Radu,
yours look more or less like a bug report. This you check existing
open bugs for neutron ? Also what version of openstack are you running
?
how did you configure enable_isolated_metadata and
enable_metadata_network options ?
Saverio
2018-06-13 12:45 GMT+02:00 Radu Popescu | eMAG, Technology
<radu.popescu at emag.ro<mailto:radu.popescu at emag.ro>>:
Hi all,
So, I'm having the following issue. I'm creating a VM with floating IP.
Everything is fine, namespace is there, postrouting and prerouting from the
internal IP to the floating IP are there. The only rules missing are the
rules to access metadata service:
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp
--dport 80 -j REDIRECT --to-ports 9697
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp
--dport 80 -j MARK --set-xmark 0x1/0xffff
(this is taken from another working namespace with iptables-save)
Forgot to mention, VM is booting ok, I have both the default route and the
one for the metadata service (cloud-init is running at boot time):
[ 57.150766] cloud-init[892]: ci-info:
+--------+------+--------------+---------------+-------+-------------------+
[ 57.150997] cloud-init[892]: ci-info: | Device | Up | Address |
Mask | Scope | Hw-Address |
[ 57.151219] cloud-init[892]: ci-info:
+--------+------+--------------+---------------+-------+-------------------+
[ 57.151431] cloud-init[892]: ci-info: | lo: | True | 127.0.0.1 |
255.0.0.0 | . | . |
[ 57.151627] cloud-init[892]: ci-info: | eth0: | True | 10.240.9.186 |
255.255.252.0 | . | fa:16:3e:43:d1:c2 |
[ 57.151815] cloud-init[892]: ci-info:
+--------+------+--------------+---------------+-------+-------------------+
[ 57.152018] cloud-init[892]: ci-info:
+++++++++++++++++++++++++++++++Route IPv4
info++++++++++++++++++++++++++++++++
[ 57.152225] cloud-init[892]: ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
[ 57.152426] cloud-init[892]: ci-info: | Route | Destination |
Gateway | Genmask | Interface | Flags |
[ 57.152621] cloud-init[892]: ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
[ 57.152813] cloud-init[892]: ci-info: | 0 | 0.0.0.0 |
10.240.8.1 | 0.0.0.0 | eth0 | UG |
[ 57.153013] cloud-init[892]: ci-info: | 1 | 10.240.1.0 |
0.0.0.0 | 255.255.255.0 | eth0 | U |
[ 57.153202] cloud-init[892]: ci-info: | 2 | 10.240.8.0 |
0.0.0.0 | 255.255.252.0 | eth0 | U |
[ 57.153397] cloud-init[892]: ci-info: | 3 | 169.254.169.254 |
10.240.8.1 | 255.255.255.255 | eth0 | UGH |
[ 57.153579] cloud-init[892]: ci-info:
+-------+-----------------+------------+-----------------+-----------+-------+
The extra route is there because the tenant has 2 subnets.
Before adding those 2 rules manually, I had this coming from cloud-init:
[ 192.451801] cloud-init[892]: 2018-06-13 12:29:26,179 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [0/120s]:
request error [('Connection aborted.', error(113, 'No route to host'))]
[ 193.456805] cloud-init[892]: 2018-06-13 12:29:27,184 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [1/120s]:
request error [('Connection aborted.', error(113, 'No route to host'))]
[ 194.461592] cloud-init[892]: 2018-06-13 12:29:28,189 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [2/120s]:
request error [('Connection aborted.', error(113, 'No route to host'))]
[ 195.466441] cloud-init[892]: 2018-06-13 12:29:29,194 -
url_helper.py[WARNING]: Calling
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [3/120s]:
request error [('Connection aborted.', error(113, 'No route to host'))]
I can see no errors in neither nova or neutron services.
In the mean time, I've searched all our nova servers for this kind of
behavior and we have 1 random namespace missing those rules on 6 of our 66
novas.
Any ideas would be greatly appreciated.
Thanks,
Radu
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180618/3e466e3c/attachment.html>
More information about the OpenStack-operators
mailing list