Re: [EXTERNAL] Re: What throughput is reasonable?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 21, 2019 at 6:44 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
>
> On Thu, 2019-03-21 at 00:13 +0000, Phillips, Tony wrote:
> > More info.  One of my coworkers and I did some more diagnostics this
> > afternoon:
> >
> > He used iperf3 to do some generic benchmarking today, and we poked
> > around in some tcpdumps taken during 1MB iperf pushes.
> >
> > When sending TCP traffic from the open connect client VM to the
> > target (an ordinary RHEL VM, recall that the VPN is terminated on a
> > hardware Palo Alto along the way) we observe an average of about
> > 2.7MB/sec with around 10% of packets getting retransmitted according
> > to both iperf and netstat -s.  The first packet that gets
> > retransmitted after the TCP socket is opened has relative sequence
> > number 4142 consistently... as in every time we tried (at least four
> > separate runs during an hour or so).
> >
> > When going in the other direction, we get 36MB/sec with about 0.3% of
> > packets getting retransmitted.  We didn’t do as much poking in these
> > dumps these since they performed 10x-15x faster, but I would hazard a
> > bet that in these cases, it’s the ACKs that are getting lost dropped.
> >
> > This definitely hints (if not shouts) at a send buffer overflow on
> > the VPN side.

Do I have this right? High packet loss from client→VPN, low packet
loss from VPN→client?

If so, I'm guessing your problems are MTU-related.

The GlobalProtect gateways seem to lack any ability to inform the
client about either (a) the MTU of the VPN internal network or (b) the
gateway's best guest of the PMTU between the client and the gateway…
at least there's no mechanism that I was able to discern while
developing the GP support in OpenConnect. The gateways actually send
an MTU field in the client configuration response
(https://gitlab.com/openconnect/openconnect/blob/v8.02/gpst.c#L622)
but it is *always zero* on real PA servers. 👎👎👎

Currently, OpenConnect just makes a guess based on the TCP path-MTU
between the client and VPN gateway:
https://gitlab.com/openconnect/openconnect/blob/v8.02/gpst.c#L322-403

Try using `--mtu` to set a smaller MTU than whatever is being guessed,
and see if that improves the client-to-VPN (upstream) throughput. The
better way to handle this would probably be to do a binary search like
what OpenConnect already does for DTLS
(https://gitlab.com/openconnect/openconnect/blob/v8.02/dtls.c#L515-625).

Dan

_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux