<div style="font-family: arial; font-size: 12px;"><div data-empty="true">I feel pretty dumb about this, but it was fixed by adding a rule to my security groups. I'm still very confused about some of the other behavior that I saw, but at least the problem is fixed now.</div><div data-empty="true"><br></div><div contenteditable="false"><div><div><div><span style="font-family: Arial, Helvetica, Sans-Serif; font-size: 12px;"><em><span style="font-family:lucida sans unicode,lucida grande,sans-serif;"><span style="font-size:16px;"><strong>Torin Woltjer</strong></span></span></em></span></div><div><span style="font-family: Arial, Helvetica, Sans-Serif; font-size: 12px;"> </span></div><div><span style="font-family: Arial, Helvetica, Sans-Serif; font-size: 12px;"><strong>Grand Dial Communications - A ZK Tech Inc. Company</strong></span></div><div><span style="font-family: Arial, Helvetica, Sans-Serif; font-size: 12px;"> </span></div><div><div><span style="font-family: Arial, Helvetica, Sans-Serif; font-size: 12px;"><strong><span class="ClickablePhoneNumber"><span class="ClickablePhoneNumber">616.776.1066</span></span> ext. 2006</strong></span></div><div><span style="font-family: Arial, Helvetica, Sans-Serif; font-size: 12px;"><em><strong><a href="http://www.granddial.com" target="_blank"><a target="_blank" href="http://www.granddial.com">www.granddial.com</a></a></strong></em></span></div></div></div></div></div><div data-empty="true"><br></div><hr id="previousmessagehr"><div><span><strong>From</strong>: Brian Haley <haleyb.dev@gmail.com><br><strong>Sent</strong>: 7/16/18 4:39 PM<br><strong>To</strong>: torin.woltjer@granddial.com, thangam.arunx@gmail.com, jpetrini@coredial.com<br><strong>Cc</strong>: openstack-operators@lists.openstack.org, openstack@lists.openstack.org<br><strong>Subject</strong>: Re: [Openstack] [Openstack-operators] Recovering from full outage</span></div><div>On 07/16/2018 08:41 AM, Torin Woltjer wrote:</div><div>> $ip netns exec qdhcp-87a5200d-057f-475d-953d-17e873a47454 curl</div><div>> <a href="http://169.254.169.254" target="_blank"><a target="_blank" href="http://169.254.169.254">http://169.254.169.254</a></a></div><div>></div><div>></div><div>>  404 Not Found</div><div>></div><div>></div><div>>  </div><h1>404 Not Found</h1><div data-empty="true"><br></div><div>>  The resource could not be found.</div><div data-empty="true"><br></div><div>></div><div>></div><div data-empty="true"><br></div><div>Strange, don't know where the reply came from for that.</div><div data-empty="true"><br></div><div>> $ip netns exec qrouter-80c3bc40-b49c-446a-926f-99811adc0c5e curl</div><div>> <a href="http://169.254.169.254" target="_blank"><a target="_blank" href="http://169.254.169.254">http://169.254.169.254</a></a></div><div>> curl: (7) Couldn't connect to server</div><div data-empty="true"><br></div><div>Based on your iptables output below, I would think the metadata proxy is</div><div>running in the qrouter namespace. However, a curl from there will not</div><div>work since it is restricted to only work for incoming packets from the</div><div>qr- device(s). You would have to try curl from a running instance.</div><div data-empty="true"><br></div><div>Is there an haproxy process running? And is it listening on port 9697</div><div>in the qrouter namespace?</div><div data-empty="true"><br></div><div>-Brian</div><div data-empty="true"><br></div><div data-empty="true"><br></div><div>> ------------------------------------------------------------------------</div><div>> *From*: "Torin Woltjer"</div><div>> *Sent*: 7/12/18 11:16 AM</div><div>> *To*: , ,</div><div>> "jpetrini@coredial.com"</div><div>> *Cc*: openstack-operators@lists.openstack.org, openstack@lists.openstack.org</div><div>> *Subject*: Re: [Openstack] [Openstack-operators] Recovering from full outage</div><div>> Checking iptables for the metadata-proxy inside of qrouter provides the</div><div>> following:</div><div>> $ip netns exec qrouter-80c3bc40-b49c-446a-926f-99811adc0c5e</div><div>> iptables-save -c | grep 169</div><div>> [0:0] -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p</div><div>> tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697</div><div>> [0:0] -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p</div><div>> tcp -m tcp --dport 80 -j MARK --set-xmark 0x1/0xffff</div><div>> Packets:Bytes are both 0, so no traffic is touching this rule?</div><div>></div><div>> Interestingly the command:</div><div>> $ip netns exec qrouter-80c3bc40-b49c-446a-926f-99811adc0c5e netstat</div><div>> -anep | grep 9697</div><div>> returns nothing, so there isn't actually anything running on 9697 in the</div><div>> network namespace...</div><div>></div><div>> This is the output without grep:</div><div>> Active Internet connections (servers and established)</div><div>> Proto Recv-Q Send-Q Local Address           Foreign Address</div><div>> State       User       Inode      PID/Program name</div><div>> raw        0      0 0.0.0.0:112             0.0.0.0:*               7</div><div>>         0          76154      8404/keepalived</div><div>> raw        0      0 0.0.0.0:112             0.0.0.0:*               7</div><div>>         0          76153      8404/keepalived</div><div>> Active UNIX domain sockets (servers and established)</div><div>> Proto RefCnt Flags       Type       State         I-Node   PID/Program</div><div>> name     Path</div><div>> unix  2      [ ]         DGRAM                    64501    7567/python2</div><div>> unix  2      [ ]         DGRAM                    79953    8403/keepalived</div><div>></div><div>> Could the reason no traffic touching the rule be that nothing is</div><div>> listening on that port, or is there a second issue down the chain?</div><div>></div><div>> Curl fails even after restarting the neutron-dhcp-agent &</div><div>> neutron-metadata agent.</div><div>></div><div>> Thank you for this, and any future help.</div></div>