<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Mar 21, 2017 at 1:22 AM Sterdnot Shaken <<a href="mailto:sterdnotshaken@gmail.com">sterdnotshaken@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Wow! Thanks for answering both of my questions!<br class="gmail_msg"><br class="gmail_msg"></div>So, I 
did some things you suggested, including setting the MSS in iperf to 
something small (1000 bytes) and tested with no improvement. I then 
changed the VM running on Openstack to have an MTU of 1000 and retested 
with no improvement. I noticed that the node I was testing against was 
reporting back to the VM on Openstack that it had an MSS of 8960, so 
just for the heck of it, I changed the remote node's (server outside of 
Openstack) MTU also to 1000 bytes and retested with no improvement. (The effects of all of these tests were also validated by checking mss settings in the tcp header via tcpdump).<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">To simplify the equation, I ditched the iperf for the time being and just did a simple "telnet 'remote server' 8080" test from the remote server to the VM in Openstack, while capturing packets all along the way (4 different points along the network path). Every point saw the same packets, including the VM's tap interface as expected. I then reversed the test by initiating the tcp session on the VM in Openstack to the remote server while running the packet captures at those same points having set the remote server to respond with a TCP Reset. From VM to Remote server traffic looked correct with expected TCP SYN. The TCP Reset that the remote server responded with passed all 4 points of the network, including the external interface on the Compute node where the VM resides, but the TAP interface that connects to the VM NEVER sees the Reset. I can recreate this condition over and over. <br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">So, thanks to your ideas Richard, I'm no longer convinced this is an MTU issue. What would prevent a TCP related response from being forwarded from the external interface to the intended VM? The security group we have applied to this VM is wide open, so I can't imagine that is the cause... <br class="gmail_msg"></div></div></blockquote><div><br></div><div>I was fighting with something quite similar to this yesterday afternoon...</div><div><br></div><div>RPF?  If the TCP response is received on an interface that is different from the interface that would be used to route to that response's source IP, RPF could drop it. </div><div><br></div><div>Another thing I wonder about - but note that this one is just speculation - is TTL.  Suppose the return path for some reason traverses more routers than the forwards path (but without triggering an RPF drop) - could the response be dropped because it had less TTL than was needed for the return path?</div><div><br></div><div>Regards,</div><div>      Neil</div><div><br></div></div></div>