<div class="gmail_quote">On Tue, May 29, 2012 at 2:47 PM, Christian Parpart <span dir="ltr"><<a href="mailto:trapni@gmail.com" target="_blank">trapni@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Hey all,</div><div><br></div><div>This 169.254.169.254 is driving me crazy. I read a few things already about that suspcisious IP address, however,</div><div>I always get either a few:</div><div><br></div><div><font face="'courier new', monospace">2012-05-29 12:22:40,831 - util.py[WARNING]: '<a href="http://169.254.169.254/2009-04-04/meta-data/instance-id" target="_blank">http://169.254.169.254/2009-04-04/meta-data/instance-id</a>' failed [50/120s]: url error [timed out]</font></div>
<div><br></div><div>or I'll get tons of:</div><div><br></div><div><div><font face="'courier new', monospace">2012-05-29 12:19:38,049 - util.py[WARNING]: '<a href="http://169.254.169.254/2009-04-04/meta-data/instance-id" target="_blank">http://169.254.169.254/2009-04-04/meta-data/instance-id</a>' failed [113/120s]: url error [[Errno 111] Connection refused]</font></div>
</div><div><br></div><div>when instantiating a new VM.</div><div><br></div><div>My setup is as follows:</div><div><br></div><div><div>"production" network: <a href="http://10.10.40.0/21" target="_blank">10.10.40.0/21</a></div>
<div>
management network (physical nodes, switches, PDUs, ...) <a href="http://10.10.0.0/19" target="_blank">10.10.0.0/19</a></div></div><div><br></div><div>nova-network: (we're not in multi_host mode)</div><div>- eth0: 10.10.30.4</div>
<div>
<br></div><div>controller (api, scheduler, etc, also compute-1 node):</div><div>- eth0: 10.10.30.190</div><div><br></div><div>compute-2:</div><div>- eth0: 10.10.30.191</div><div><br></div><div>compute-3:</div><div>- eth0: 10.10.30.192</div>
<div><br></div><div>Now, since the 169.254.169.254 is just an artificial IP, to be NAT'ed to the right host via iptables, I did a quick check,</div><div>and tcp/80 seems to redirect to the nova-api instance at port 8775.</div>
<div><br></div><div>So here's my question:</div><div>On which physical nodes is this iptables rule expected, Just nova-network or on every compute node? (and how to fix my above situation?)</div><div><br></div><div>I'm asking because I found the DNAT rule on the dedicated network node but also compute-1 node (which is also the controller node, with api, scheduler, etc) but not on compute-3 nor on compute-3 node - regardless of my issue, this doesn't feel right.</div>
</blockquote><div><br></div><div>Hey,</div><div><br></div><div>for the latter case (ECONNREFUSED) I believe I have an answer, but not why it is set up this way:</div><div><br></div><div>root@nova-network-node:/etc/nova# iptables -t nat -L -vn | grep -n3 169.254.169.254</div>
<div>26-</div><div>27-Chain nova-network-PREROUTING (1 references)</div><div>28- pkts bytes target prot opt in out source destination </div><div>29: 33 1980 DNAT tcp -- * * <a href="http://0.0.0.0/0">0.0.0.0/0</a> 169.254.169.254 tcp dpt:80 to:<a href="http://10.10.40.1:8775">10.10.40.1:8775</a></div>
<div>30- 0 0 DNAT udp -- * * <a href="http://0.0.0.0/0">0.0.0.0/0</a> 10.10.40.1 udp dpt:1000 to:<a href="http://10.10.40.2:1194">10.10.40.2:1194</a></div><div>31-</div><div>
<br></div><div>This shows, that the suspicious IP address is routed to <a href="http://10.10.40.1:8875">10.10.40.1:8875</a> where this IP</div><div>is the host itself and not the nova-api node's IP.</div><div><br></div>
<div>AFAIK nova-api is just to be installed onto a single node, that is, the controller node, so I wonder</div><div>why nova-network seems to create a DNAT rule for nova-api to its own host instead to the cloud controller's IP.</div>
<div><br></div><div>I checked my nova.conf, and while there is no direct entry for what IP to use for node-api, I at least</div><div>see, that cc_host is set to the proper IP (10.10.30.190).</div><div><br></div><div>So long,</div>
<div>Christian Parpart.</div><div><br></div></div>