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