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.pope...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators