Re: PPTPD upload speed bottleneck

Greg Scott <[email protected]> Sun, 17 Nov 2013 10:58:02 +0000
Newsgroups gmane.network.poptop
Message-ID <[email protected]>
You want to make your tunnel MTU a little bit smaller than the smallest ISP router MTU in the path.  I usually just used whatever default MTU value was in place for the raw interfaces.  I don’t remember anything other than 1500.  So I generally used an MTU of 1400 for my tunnels, figuring 100 bytes should be plenty for whatever overhead was needed.  Almost every ISP I’ve ever run across uses an MTU of 1500 across their routers.

I had one case where every time somebody started an RDP session over the tunnel, the whole tunnel dropped and the user had to reconnect.  Everything else other than RDP worked fine.  Very strange.  In this case, the ISP at the customer site did funny stuff with its MTU, and RDP apparently uses big packets.   So I had to make my tunnel MTU smaller than the ISP MTU.  These are the firewall rules I settled on:

echo "Handling potential MTU problems"
# Thanks to Phil Mayers <[email protected]> who answered my query
# in PopTop-server Digest on July 18, 2007.  Also see the iptables man
# pages
$IPTABLES -t mangle -A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN SYN \
                -m tcpmss --mss 1301:65535 -j TCPMSS --set-mss 1300

$IPTABLES -t mangle -A FORWARD -o ppp+ -p tcp -m tcp --tcp-flags SYN SYN \
                -m tcpmss --mss 1301:65535 -j TCPMSS --set-mss 1300

In your case, why is tunnel traffic in one direction slow, while tunnel traffic the other direction seems OK?  I don’t know, but one possible explanation might be that one of the ISPs uses a small MTU value and the tunnel adds enough overhead that the packets fragment going that direction but not the other direction.


-          Greg

Greg Scott
Infrasupport Corporation
[email protected]<mailto:[email protected]>

Direct 1-651-260-1051

From: Gustavo Homem [mailto:[email protected]]
Sent: Sunday, November 17, 2013 4:41 AM
To: Greg Scott; [email protected]
Subject: RE: [Poptop-server] PPTPD upload speed bottleneck

Hi Greg,

The mtu is 996 on both ends - I havent changed it, that is the default. It would fragment each large packet in two adding the overhead of headers. I can push it two 1400 but do you think this could explain such a large discrepance of upload rates between network and vpn? Why doesn't the same discrepance show for download rates?

Can you share what values you obtain?

Cheers
Gustavo
--
Angulo Sólido - Tecnologias de Informação
http://angulosolido.pt
Greg Scott <[email protected]<mailto:[email protected]>> wrote:

MTU issues maybe?  The PPTP tunnel will gobble a few bytes for tunnel overhead so you don't get the full MTU of the physical interfaces.  If both endpoints "think" the MTU size is 1500 for the raw physical interfaces and they're sending large packets, maybe the tunnel is fragmenting the packets and putting them back together on the receiving end.  Just a guess.

- Greg

-----Original Message-----
From: Gustavo Homem [mailto:[email protected]]
Sent: Saturday, November 16, 2013 4:32 PM
To: [email protected]<mailto:[email protected]>
Subject: [Poptop-server] PPTPD upload speed bottleneck

Hi,

We are using PPTPD with a high performance connection and the upload speed appears to be artificially limited. This was not an issue in the past with ADSL connections but now that fiber is becoming available it became noticeable.

The network connection between PPTP client and PPTPD is as follows:

upstream  10Mbps
downstream 100Mbps
latency ~ 7-15ms
packet loss 0%

Command line scp transfer performance between end points WITHOUT using the VPN is:

up  ~ 700KB/s
down ~ 1100MB/s

Command line scp transfer performance using the VPN is:

up ~ 160 KB/s
down ~ 1000 KB/s

The values are in KBytes and were measured by the scp command.

So clearly, there is a problem with the upstream transfers (client -> server) through the VPN.

We've debugged this enough to know that CPU is not an issue (neither or the router, nor on the server), that there is no packet loss and that there is no other bottleneck. We tested this with traffic shapping turned off. We have read on the docs that the speed option does not affect pppd on Linux. We tried --nobuffer on the client, which made no difference. We also made tran

 sfers

using time+netcat just to be sure scp wasn't screwing things - no difference either.

Interestingly, when an upstream transfer is done, using scp trough the VPN, and the rate stabilizes at 160 KB/s the pings between the client and the VPN server interface behave as if a packet queue was saturated, with rtt fluctuations between 14ms and 700ms, but at the exact same time we can ping the public server interface - through which the VPNn traffic flows as well - and the pings retain their normal values of between 7 and 15ms. When pinging the VPN server interface with an interval of 0.1 (ping -i 0.1) we can see the latency varying like a cosine between normal and large values, which suggests a queue is filled and then emptied in a loop. There is absolutely no packet loss that would justify this behaviour.

In short, in the router where the pptp client runs interface ppp0 appears to get saturated, but interface eth1 where the ppp0 traffic is tunneled through doesn

 't show

any problem.

So, either the PPPD client or PPTPD is limiting the traffic rate to something way below the connection rate and, therefore, queuing happens. Which one would it be and why?

On the server side we are using pptpd-1.4.0-1.rhel5 and on the client pptp-1.7.2-8.1.el5.rf.

Cheers
Gustavo

Cheers
Gustavo

--
Angulo Sólido - Tecnologias de Informação http://angulosolido.pt

________________________________

DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk

________________________________

Poptop-server mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/poptop-server

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk

_______________________________________________
Poptop-server mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/poptop-server