<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Steps to debug.<br>
<ol style="font-family: Tahoma; font-size: 10pt;">
<li>Understand where exactly the problem lies
<ol>
<li>Are you not able to reach the floating ip of instances?
<ol>
<li>First start a continuous ping from an machine outside openstack to the floating ip</li><li>Go to network node. Find the interface of the router that attaches your external network to the br-ex(external bridge, you should see it in bridge_mappings, the one with no vlan id ranges in its corresponding network_vlan_ranges)</li><li>Note: This interface might not be in default network node host's namespace. It would exists inside the namespace that was created for your router. Your namespace for your router would normally be something like 'qrouter-<router_id>' and you can view it
using 'ip netns' command. <br>
</li><li>Do 'tcpdump -lennvi <the interface>. To do this you would have to execute tcpdump inside the namespace mentioned above. You can do that by 'ip netns exec <namespace id> tcpdump -lennvi <interface_name></li><li>In your tcpdump do you see the ping requests arriving?
<ol>
<li>No?<br>
<ol>
<li>If you do not see them then it might be that your physical network interface (say eth3) attached to br-ex is not in promiscous mode or it is not up.</li><li>So you do 'ip link set <physical_interface> up', 'ip link set <physical_interface> promisc on'</li></ol>
</li><li>Yes?
<ol>
<li>Go on the next step. Find the network interface attaching your router(external router) to your instance's network. Again it will be inside the same network namespace and to the tcpdump there.</li><li>Here you should see the same ping request except that the ip you are pinging should be the private ip and not the floating ip. If this is not happening the problem lies in your neutron l3 agent and /or firewall driver.
<br>
<ol>
<li>If this too is happening you have to go to the below subject.<br>
</li></ol>
</li></ol>
</li></ol>
</li></ol>
</li><li>Are the instances not able to reach other through their private ip itself?
<ol>
<li>This could mean that your instance would also not be able to reach its gateway router. The router that is responsible for floating ip mapping and inter subnet connectivity.</li><li>To check this start a continuous ping from one of the instances in openstack to the gateway router interface for that subnet.</li><li>Start tracing where your packets are dropped using tcpdump. Below is the list of interface you are to look in the order from instance to router.
<ol>
<li>The tap device attached to the instance. You can find this in the openstack dashboard page of the network.</li><li>'int-br-eth1' <br>
</li><li>'phy-br-eth1' at this interface the ping packets should carry a vlan(if you are using vlan mode)</li><li>eth1( I am assuming that your physnet is bridged to br-eth1 and eth1 is attached to br-eth1) here the packets should carry a vlan id that was assigned to the openstack network while you created it.</li><li>eth1 of the network node. 'phy-br-eth1', 'int-br-eth1' of network node. Then to the interface of the router in the instance's network</li></ol>
</li></ol>
</li></ol>
</li></ol>
<p><br>
</p>
<p>I agree Its too cryptic and would not make sense on first look but if you study the way neutron openvswitch agent works, you will see the flow I have mentioned above. If you could tell me where exactly your packet goes missing I could find a possible reason
and solution to prevent outages.</p>
<p><br>
</p>
<p>There is however another way to debug using ovs-ofctl dump-flows on br-int and br-eth1 on both compute and network node. But this assumes that all flows are correctly programmed.<br>
</p>
<p><br>
</p>
<p>Thank you,</p>
<p>Ageeleshwar K<br>
</p>
<br>
<br>
<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF126209"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Akshat Kansal [akshatknsl@gmail.com]<br>
<b>Sent:</b> Thursday, April 10, 2014 1:26 PM<br>
<b>To:</b> Robert van Leeuwen<br>
<b>Cc:</b> openstack@lists.openstack.org<br>
<b>Subject:</b> Re: [Openstack] quantum openvswitch agent on compute nodes stops working.<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Thanks Robert,
<div><br>
</div>
<div>Yes other components still work, openvswitch works fine as no flows are dropped.</div>
<div>I even do not see any error in the logs, but still it stops working.</div>
<div><br>
</div>
<div>Also, after the restart it starts working fine,so I don't doubt the space in rabbit message queue to be a problem.</div>
<div><br>
</div>
<div>Regards</div>
<div>Akshat</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 10, 2014 at 11:23 AM, Robert van Leeuwen <span dir="ltr">
<<a href="mailto:Robert.vanLeeuwen@spilgames.com" target="_blank">Robert.vanLeeuwen@spilgames.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-size:10pt; font-family:Tahoma">
<div style="font-size:16px; font-family:Times New Roman">
<div>
<div dir="ltr">
<div>
<div class="h5">> I am facing a issue, where all of a sudden the quantum openvswitch agent stops working and all the VMs lose
<br>
> connectivity and even the provisioning fails.
<div>><br>
</div>
<div>>Also, I also want to understand what is the role of quantum openvswitch agent.</div>
<div>><br>
>Any pointer will be helpful.</div>
<br>
</div>
</div>
The agent setups the Openvswitch flows (ovs-ofctl dump-flows). <br>
I think it also creates the interfaces to be patched into the vms.<br>
<br>
What does the openvswitch logs say? Do other components still work?<br>
<br>
I think I saw something similar when rabbitmq did not have enough space (it needs at least 1GB free space).<br>
You would be able to connect to rabbitmq (so no errors in the logs) but it stopped processing messages.<br>
<br>
Cheers,<br>
Robert van Leeuwen<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
http://www.csscorp.com/common/email-disclaimer.php
</body>
</html>