David et al.: sorry for the delayed response!
> Hm, is there a way to eliminate that difference? Given that we're still
> kind of confused about what's causing this, it would be good to
> eliminate all differences, even if they don't *seem* likely to be part
> of the problem.
Given the bazillion things we tried before engaging y’all, I’d forgotten that we tried the same VM without any VPN at all. I recalled that when I went through my emails from early March when we did that.
It worked at near wire-rate on the same VM cluster, same path all the way.
> Watching the network status in both VM and host side
> (and the egress from the host towards the VPN server... do they concur?
> Are they only seeing ~150MB/s coming out of the guest in the first
> place?
Careful to note that iperf shows 166 megaBITS (not bytes) per second... and, yes, the receiving end concurs.
Also, looking at the vCenter VM monitor, it shows roughly that amount on the vNIC.
> IF you watch the sendq ('netstat -un') while the transfer is happening, does it stay
> fairly full or is it fluctuating?
Did the following (and added the column headings after the fact) while WRITING a 1 gigabyte file (took 41.5s wall time at 24.1MB/sec)
# while true; do netstat -un | grep udp; sleep 1; done
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 6528 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 10880 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 5888 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 8704 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 4352 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 2176 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 8704 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 4608 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 6912 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
udp 0 0 10.181.43.21:49437 10.248.255.67:4501 ESTABLISHED
> What was the alternative setup that was getting line rate from this
> VPN? Was it the same VM host, and guest kernel?
It was the legit Palo Alto Global Protect linux client... but that won't work in our case because it requires a user to be logged in to start the client. Our use case is initialized via a systemd script to keep the tunnel ALWAYS up.
Can never expect whether it was the same host or not because VMWare DRS moves things around. The guest kernel was the same one.
_______________________________________________
openconnect-devel mailing list
openconnect-devel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/openconnect-devel
