[ale] http behind pppoe ?
matty91 at bellsouth.net
matty91 at bellsouth.net
Fri Jan 24 23:28:31 EST 2003
On Fri, 24 Jan 2003, Keith R. Watson wrote:
> At 12:38 PM 1/24/2003 -0500, James CE Johnson wrote:
>
> >I'm unfortunate enough to live behind the bastardization that is PPPoE
> >rather than having a nice, static IP. Since the switch (from the nice,
> >static IP to the bastardization that is PPPoE) I've noticed that web
> >requests to my server seem to have "issues". To be specific, it seems that
> >in some cases the browser isn't getting the entire page sent by the
> >server.
> >
> >Other protocols (eg -- ssh) seem to exhibit similar behavior but since the
> >bulk of my traffic is http that's where I see it most.
> >
> >I have absolutely no idea why this is happening but I'm hoping someone out
> >there in ALE-land has already been down this dark and disturbing road and
> >will be kind enough to lend me a hand.
> >
> >Thanks,
> >J
>
>
> James,
>
> When we first started using Cable/DSL routers such Linksys with ISP's that
> use PPPOE, we encountered problems. I spent a day resolving the issue. Here
> is a copy of the report.
>
> keith
>
>
> VPN Connection to Georgia Tech Over Residential ADSL Test
>
> Keith R. Watson
> keith.watson at gtri.gatech.edu
>
> 4/25/2001
>
> Test machines:
>
> Windows NT 4.0 (AIST Build v3.01)
> Windows 98 SE (Standard KRW home build)
>
>
> Test Network:
>
> Earthlink residential ADSL using PPPOE
> ZyXEL Prestige 642M ATM to Ethernet bridge (DSL modem)
> Linksys BEFSR41 NAT Router with BIOS v1.37 (PPPOE provided by BEFSR41)
> 10 Port 10Mb Ethernet Hub
>
> (Also did a series of tests using WinPoET v2.0
> on both machines. The results were the same as
> using the BEFSR41)
>
>
> Software:
>
> WinPoET v2.0
> Secure Remote v4.1
>
>
> Test Scenario:
>
> 1. Establish VPN connection to the Georgia Tech Checkpoint Firewall
> 2. Mount an SMB share
> 3. Copy a large file from the SMB share (>1K)
> 4. Establish Telnet session to casbah.gatech.edu
> 5. Connect to https://webwise.gtri.gatech.edu/
>
>
> Tests (results were the same for both workstations):
>
> MTU = 1500 (this is the default for ethernet
>
> 1. Established VPN
> 2. SMB mount succeeded.
> 3. File copy <1K succeeded, >1K failed
> 4. Telnet succeeded
> 5. https failed
>
>
> MTU = 576
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copiy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https succeeded
>
>
> MTU = 1464
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K failed
> 4. Telnet succeeded
> 5. https failed
>
>
> MTU = 1400
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https succeeded
>
>
> MTU = 1440
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https failed
>
>
> MTU = 1420
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https succeeded
>
>
> MTU = 1430
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https succeeded
>
>
> MTU = 1435
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https succeeded
>
>
> MTU = 1438
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https succeeded
>
>
> MTU = 1439
>
> 1. Established VPN
> 2. SMB mount succeeded
> 3. File copy <1K succeeded, >1K succeeded
> 4. Telnet succeeded
> 5. https failed
>
>
> Conclusions:
>
> A larger header is required for HTTPS over a VPN.
> When the MTU is set to 1500 the packets are fragmented
> whenever the data size to be transmitted is >1K.
>
> header size + data size > 1500 bytes
>
This is definitely a cool topic. I am using a MTU size of 1454 (No IPSEC)
with my FreeBSD 4.7-RELEASE-p3 firewall. I spent a good deal of time
researching the internals of PPP/ATM/Ethernet, and came up with this
value based on the following information:
Data = ?? Bytes
TCP Header = 20 Bytes
IP Header = 20 Bytes
PPP Headers = 8 Bytes (Assumes address/control fields
are omitted)
Ethernet Headers = 18 Bytes
ATM Cell = 53 Bytes (48 Bytes data, 5 bytes for headers)
--
66 Bytes
After looking at this info, I wanted to find a combination of
headers and data that would fill each and every 53 byte ATM
cell. I did some math, and determined that 1414 bytes of data
could be encapsulated within each TCP segment:
1414 bytes of data + 66 bytes worth of headers / 48 bytes \
= 30 cells w/ 48 bytes, and one cell with 40 bytes
ATM also requires an 8 byte Segmentation and Reassembly trailer for each
frame (similar to the IP identification field). If we factor in the
trailer:
(1480 (headers + data) + 8 bytes (segmentation and reassembly trailer) \
= 1488) / 48 = 31
Now as long as I read TCP/IP Illustrated I, and my deploying ADSL book
correctly, all the numbers should be correct (please let me know if you
see anythign fubar). This should optimize large transfers of
data on your PPPoE connection, since you are filling each and every
ATM cell. Since I am a geek and like to keep up to date with new
releases of RedHat, I tend to pull down 600MB ISOs when they become
available. Since ATM requires all cells to be padded to 53 bytes, you
might as well fill each byte with something. As you can tell, I am not a
big fan of padding. :)
Hope this is helpful,
- Ryan
>
> Setting MTU to 1438 prevents the packets
> from fragmenting by limiting the amount of data in
> the packet.
>
> header size + data size = 1500 bytes
>
>
> Since not all possible scenarios were tested
> an MTU value of less than 1438 should be used
> to provide a safety margin. However, as MTU
> decreases more packets are needed to send the
> same amount of data. Therefore a safe compromise
> would be to set MTU to 1400.
>
> -------------
>
> Keith R. Watson GTRI/ITD
> Systems Support Specialist III Georgia Tech Research Institute
> keith.watson at gtri.gatech.edu Atlanta, GA 30332-0816
> 404-894-0836
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale
More information about the Ale
mailing list