<div dir="ltr"><div><div>I'm Maximiliano Venesio from MercadoLibre and i have been working with Alejandro in this issue. </div><div><br></div><div>In order to answer your last questions : </div><div><br></div><div>We are injecting the iptables PREROUTING rule directly to the compute node (host machine), as is configured and working in essex.</div>
<div>regarding the question about if the metadata server knows how to route the packets back to the tenant network, the problem that we are having now is that the NATed packet is not passing out trough the bridge, so never hits the metadata server, that in our case, is the controller node that is running in a different physical server. </div>
<div><br></div><div>When we try to reach the metadata directly from the VM to the controller IP port 8775, we can get the metadata info perfectly. So we think that the problem is with the PREROUTING rule using the 169.254.169.254, or some issue between the bridge and the veth pairs.</div>
</div><div><br></div><div><div>Regarding the integration with neutron + nova + OVS, we are not using service_neutron_metadata_proxy, but i think that it comes disabled by default. As i have understood the service_neutron_metadata_proxy is used with the network node and we are not using any network node or L3 agent or DHCP agent.</div>
<div>We just configured LibvirtHybridOVSBridgeDriver to have nova-compute working with OpenVswitch and the neutron-openvswitch-agent to connect neutron with the compute node. </div><div><br></div><div>Yes, its really strange since we can see the packet passing trough the tap interface , then matching the iptables rule, and finally coming to the qbrXXX with the NAT rule applied but it never pass from the bridge to the qvbXXXX or qvoXXX, and we can't see any iptables rule <span style="font-family:arial,sans-serif;font-size:13px">dropping the package. So we are using tcpdump in all the steps tap bridge and veth and it works fine in the first two.</span></div>
</div><div><br></div><div>Just to clarify some details about our setup, we are injecting the ip and the gateway to the VM using flat_injected and flat_network_bridge, and we are using one of our cloud core switches as a default gw.<br>
</div><div><br></div><div><br></div><div><br></div><div>Thanks in advanced </div></div><div class="gmail_extra"><br clear="all"><div><div><font style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><b><br>
</b></font></div><font style="background-color:rgb(255,255,255)"><div style="font-weight:bold"><font style="background-color:rgb(255,255,255)" color="#888888" face="arial, sans-serif"><img src="http://s14.postimage.org/sg1lztqep/cloudbuilders_Logo_last_small.png" width="96" height="58"></font></div>
<div style="font-weight:bold"><font style="background-color:rgb(255,255,255)" color="#888888" face="arial, sans-serif"><br></font></div><font face="arial, sans-serif"><b><font color="#333333">Maximiliano Venesio</font><font color="#888888"> </font></b></font><br>
<font color="#888888" face="arial, sans-serif" style="font-weight:bold">#melicloud CloudBuilders</font></font><br style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font color="#666666" style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><span lang="ES" style="font-size:6pt;color:gray">Arias 3751, Piso 7 (C1430CRG) <br>Ciudad de Buenos Aires - Argentina<br>
Cel: +549(11) 15-3770-1853<br>Tel : +54(11) 4640-8411</span></font></div>
<br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 7:59 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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"><div class="im">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><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 class="im">
<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><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 class="im">
<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></div>_______________________________________________<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" target="_blank">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>
<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>