<div dir="auto">Can you do a tcpdump to see if the VM is sending any packets out that other interface with the source mac of the primary interface? <div dir="auto"><br></div><div dir="auto">We make use of the NORMAL action which does mac learning so it's possible something is slipping through that is causing OVS to get the wrong port association. </div><div dir="auto"><br></div><div dir="auto">The other possibility is that the ARP entry on the upstream router is learning the secondary MAC for the IP of the primary due to some traffic slipping out. </div><div dir="auto"><br></div><div dir="auto">Seeing the dest MAC of upstream traffic going into the filtering bridge of the secondary interface should tell you if it's a Mac learning problem or an arp problem. </div><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Jun 21, 2017 10:52, "Jonathan Proulx" <<a href="mailto:jon@csail.mit.edu">jon@csail.mit.edu</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
So this all gets more interesting the packets aren't lost they get<br>
routed (switched?) to the wrong interface...<br>
<br>
<br>
The VM has two interfaces on the same network. Not sure this makes<br>
sense and wes done because this was a straight physical to virtual<br>
migration.  But seems like it should work<br>
<br>
so VM is sending SYN from it's (vm)eth0 -> tap0 -> qvb0 -> qvo0 -> int-eth1-br<br>
-> phy-eht1-br -> (hypervisor)eth1 -> WORLD<br>
<br>
but the ACK is coming back (hypervisor)eth1 ->  phy-eht1-br -><br>
int-eth1-br -> qvo1 !!! -> qvb1 -> tap1 where presumablely sec-group<br>
rules see it as invalid and drop it.<br>
<br>
This is quite odd.  Default route on VM is through eth0 where packets<br>
are originatine and where teh ipv4 address it should return to is.<br>
<br>
really puzzled why OVS is sending packets back through wrong path.<br>
<br>
on the one hand I want to say stop doing that just put both addresses<br>
on one port, on the other I see no reason why it shouldn't work.<br>
<br>
-Jon<br>
<br>
<br>
On Wed, Jun 21, 2017 at 05:35:02PM +0100, Stig Telfer wrote:<br>
:Hi Jon -<br>
<div class="quoted-text">:<br>
:From what I understand, while you might have gone to the trouble of configuring a lossless data centre ethernet, that guarantee of packet loss ends at the hypervisor. OVS (and other virtual switches) will drop packets rather than exert back pressure.<br>
:<br>
:I saw a useful paper from IBM Zurich on developing a flow-controlled virtual switch:<br>
:<br>
</div>:<a href="http://researcher.ibm.com/researcher/files/zurich-DCR/Got%20Loss%20Get%20zOVN.pdf" rel="noreferrer" target="_blank">http://researcher.ibm.com/<wbr>researcher/files/zurich-DCR/<wbr>Got%20Loss%20Get%20zOVN.pdf</a> <<a href="http://researcher.ibm.com/researcher/files/zurich-DCR/Got%20Loss%20Get%20zOVN.pdf" rel="noreferrer" target="_blank">http://researcher.ibm.com/<wbr>researcher/files/zurich-DCR/<wbr>Got%20Loss%20Get%20zOVN.pdf</a>><br>
<div class="elided-text">:<br>
:It’s a bit dated (2013) but may still apply.<br>
:<br>
:If you figure out a way of preventing this with modern OVS, I’d be very interested to know.<br>
:<br>
:Best wishes,<br>
:Stig<br>
:<br>
:<br>
:> On 21 Jun 2017, at 16:24, Jonathan Proulx <<a href="mailto:jon@csail.mit.edu">jon@csail.mit.edu</a>> wrote:<br>
:><br>
:> On Wed, Jun 21, 2017 at 02:39:23AM -0700, Kevin Benton wrote:<br>
:> :Are there any events going on during these outages that would cause<br>
:> :reprogramming by the Neutron agent? (e.g. port updates) If not, it's likely<br>
:> :an OVS issue and you might want to cross-post to the ovs-discuss mailing<br>
:> :list.<br>
:><br>
:> Guess I'll have to wander deeper into OVS land.<br>
:><br>
:> No agent updates and nothing in ovs logs (at INFO), flipping to Debug<br>
:> and there's so many messages they get dropped:<br>
:><br>
:> 017-06-21T15:15:36.972Z|00794|<wbr>dpif(handler12)|DBG|Dropped 35 log messages in last 0 seconds (most recently, 0 seconds ago) due to excessive rate<br>
:><br>
:> /me wanders over to ovs-discuss<br>
:><br>
:> Thanks,<br>
:> -Jon<br>
:><br>
:> :Can you check the vswitch logs during the packet loss to see if there are<br>
:> :any messages indicating a reason? If that doesn't show anything and it can<br>
:> :be reliably reproduced, it might be worth increasing the logging for the<br>
:> :vswitch to debug.<br>
:> :<br>
:> :<br>
:> :<br>
:> :On Tue, Jun 20, 2017 at 12:36 PM, Jonathan Proulx <<a href="mailto:jon@csail.mit.edu">jon@csail.mit.edu</a>> wrote:<br>
:> :<br>
:> :> 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>
:> :><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>
:> :><br>
:><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>
</div>:<br>
<br>
--<br>
</blockquote></div><br></div></div>