<div dir="ltr">Are there any events going on during these outages that would cause reprogramming by the Neutron agent? (e.g. port updates) If not, it's likely an OVS issue and you might want to cross-post to the ovs-discuss mailing list.<div><br></div><div>Can you check the vswitch logs during the packet loss to see if there are any messages indicating a reason? If that doesn't show anything and it can be reliably reproduced, it might be worth increasing the logging for the vswitch to debug.<div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 20, 2017 at 12:36 PM, Jonathan Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All,<br>
<br>
I have a very busy VM (well one of my users does I don't have access<br>
but do have cooperative and copentent admin to interact with on th<br>
eother end).<br>
<br>
At peak times it *sometimes* misses packets.  I've been didding in for<br>
a bit ant it looks like they get dropped in OVS land.<br>
<br>
The VM's main function in life is to pull down webpages from other<br>
sites and analyze as requested.  During peak times ( EU/US working<br>
hours ) it sometimes hangs some requests and sometimes fails.<br>
<br>
Looking at traffic the out bound SYN request from VM is always good<br>
and returning ACK always gets to physical interface of the hypervisosr<br>
(on a provider vlan).<br>
<br>
When packets get dropped they do not make it to the qvoXXXXXXXX-XX on<br>
the integration bridge.<br>
<br>
My suspicion is that OVS isn't keeping up eth1-br flow rules remaping<br>
from external to internal vlan-id but neither quite sure how to prove<br>
that or what to do about it.<br>
<br>
My initial though had been to blame contrack but drops are happening<br>
before the iptables rules and while there's a lot of connections on<br>
this hypervisor:<br>
<br>
net.netfilter.nf_conntrack_<wbr>count = 351880<br>
<br>
There should be plent of overhead to handle:<br>
<br>
net.netfilter.nf_conntrack_max = 1048576<br>
<br>
Anyone have thought son where to go with this?<br>
<br>
version details:<br>
Ubuntu 14.04<br>
OpenStack Mitaka<br>
ovs-vsctl (Open vSwitch) 2.5.0<br>
<br>
Thanks,<br>
-Jon<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</font></span></blockquote></div><br></div>