Open Stack

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>:
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>