<div dir="ltr">Hi Alejandro,<div><br></div><div>As we've already discussed the topic over IRC, let me add something else on your setup:</div><div>- no dhcp agent, no l3 agent</div><div>- IP configuration injected into instances</div>
<div>(I'm disclosing this information since it's already been disclosed on IRC whose logs are publicly accessible anyway)</div><div><br></div><div>Comments inline</div><div><br></div><div>Regards,</div><div>Salvatore</div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 November 2013 23:38, Alejandro Comisario <span dir="ltr"><<a href="mailto:alejandro.comisario@mercadolibre.com" target="_blank">alejandro.comisario@mercadolibre.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small;font-family:'courier new',monospace">
Hi guys, we are deploying: </div><div style="font-size:small;font-family:'courier new',monospace">
<br></div><div style="font-size:small;font-family:'courier new',monospace">havana + OVS on vlan mode + neutron using this EXACT production schema : </div><div style="font-size:small;font-family:'courier new',monospace">
<br></div><div style="font-size:small;font-family:'courier new',monospace"><a href="http://docs.openstack.org/network-admin/admin/content/figures/2/figures/under-the-hood-scenario-2-ovs-compute.png" target="_blank">http://docs.openstack.org/network-admin/admin/content/figures/2/figures/under-the-hood-scenario-2-ovs-compute.png</a><br>
</div><div style="font-size:small;font-family:'courier new',monospace"><br></div><div style="font-size:small;font-family:'courier new',monospace">
Since we are using this schema, im gonna reffer about devices as they are named in the picture.</div><div style="font-size:small;font-family:'courier new',monospace">When an instance gets created, the network defined uses the GW where the vlan is created on a switch, so when the VM tries to access any other network packets go through all the taps, and bridges inside de compute and get to the default gw where it gets routed.</div>
<div style="font-size:small;font-family:'courier new',monospace"><br></div><div><font color="#000000" face="courier new, monospace">Regarding metadata, the instances cant access the metadata, so i issue the regular DNAT iptables rule to be able to acces it :</font></div>
<div><font color="#000000" face="courier new, monospace"><br></font></div><div><font color="#000000" face="courier new, monospace">iptables -t nat -A neutron-openvswi-PREROUTING -d <a href="http://169.254.169.254/32" target="_blank">169.254.169.254/32</a> -p tcp -m tcp --dport 80 -j DNAT --to-destination [CONTROLLER-IP]:8775<br>
</font></div><div><font color="#000000" face="courier new, monospace"><br></font></div></div></blockquote><div><br></div><div>Are you injecting this rule into the instances or into the host machine?</div><div>In any case I think this will cause the packet received by the metadata server to have the SRC IP of the VM instance, which is on a tenant network. Does the metadata server know how to route packets back to tenant networks?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><font color="#000000" face="courier new, monospace"></font></div>
<div><span style="font-family:'courier new',monospace">I see the original package exit the TAP, the DNATED package incoming the qbrXXX but the package never hits the qvbXXXX interface </span><span style="font-family:'courier new',monospace">and we dont have an idea why, since it doesnt seems to be an iptables issue.</span></div>
</div></blockquote><div><br></div><div>I would add to the potential issues that nova might expect you to run neutron metadata proxies/agent if service_neutron_metadata_proxy is true.</div><div>However, I think that can be turned off, and anyway you're now experiencing a connectivity problem.</div>
<div><br></div><div>It is really strange that a packet gets lost in the bridge, unless the host has some iptables rule which will end up dropping the packet.</div><div>I don't know how tcpdump works with veths, so perhaps I would check if the packets makes it into br-int.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<div><span style="font-family:'courier new',monospace"><br></span></div><div><font color="#000000" face="courier new, monospace">can anyone help me ?</font></div>
<div><div><font><b><div style="font-size:small;display:inline;font-family:'courier new',monospace"></div></b></font></div></div><div><font><b><div style="font-size:small;display:inline;font-family:'courier new',monospace">
alejandrito @catintheroof</div></b></font></div>
</div>
<br>_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div><br></div></div></div>