Open Stack

On Tue, Mar 21, 2017 at 1:22 AM Sterdnot Shaken <sterdnotshaken at gmail.com>
wrote:

> Wow! Thanks for answering both of my questions!
>
> 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).
>
> 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.
>
> 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...
>

I was fighting with something quite similar to this yesterday afternoon...

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.

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?

Regards,
      Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170321/e95ff7d2/attachment.html>