Topic: 1500 byte MTU on FTTC, possible. (Read 21678 times)

Chrysalis · « **on:** August 22, 2013, 06:58:41 PM »

so as some may know using a homehub one can have a 1500 byte MTU on FTTC.

Sky is excluded on this as they dont use PPPoE.

Most other routers, especially in default states are limited to a 1492 byte MTU.

AAISP made some noise about this when they modified their firebrick devices to allow a 1500 byte MTU to be used, they did this by enabling baby jumbo frames and allowing the interface to have a MTU higher than 1500 so the overheads of pppoe do not eat into the 1500 bytes.

I also read on some other sites that the version of the ppp software used on tomato firmware's was patched to support higher mtu values, although people were having issues getting it to work due to the tomato code forcing lower mtu values (probably as dummy protection). The dev had posted he would remove this handholding of mtu but not much else was said.

So last night I flashed the latest shibby firmware on to my asus rt-n16. Which is v1.28. I am using the AIO version.

I configured the device whilst it was offline (pc online via 3G tethering), enabled jumbo frames on PC (not sure if this bit needed), enabled jumbo frames on the router, manually set the mtu to 1500 on the pppoe config page on the router and added mru 1500 mtu 1500 to the optoins field (not sure if this bit needed either). I manually set the eth0 and vlan2 interfaces to 1508 mtu's inside ssh on the router. (pppoe has 8bytes overhead).

Then I started up the ppp session and watched. The shibby gui reported 1492 bytes of mtu which wasnt good, but the router was still offline so I didnt immediatly click what was going on, eventually I decided and hoped it was a just a gui thing and recconected the router back to the wan cable.

The result was the gui still reports 1492 but this I now know is not real, inside the router the ppp interface has a 1500 byte mtu and the values I set on eth0 and vlan2 were not overuled by the scripts and vlan1 was also set to 1508 mtu. I tested on speedguide.net's analyzer and non fragemented pings (after I set pc to 1500 mtu) which confirms 1500 bytes is working over the internet.

so its possible, and without a firebrick, without a homehub, using a common consumer router. Its almost certian this can also be done on a asus rt-n66.

Code: [Select]

root@TomatoASUS:/tmp/home/root# ifconfig
br0        Link encap:Ethernet  HWaddr xxxxxxxx  
           inet addr:192.168.1.253  Bcast:192.168.1.255  Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:3936894 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3865796 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0 
           RX bytes:339652520 (323.9 MiB)  TX bytes:1140652959 (1.0 GiB)

eth0       Link encap:Ethernet  HWaddr xxxxxxxx  
           UP BROADCAST RUNNING MULTICAST  MTU:1508  Metric:1
           RX packets:7683483 errors:0 dropped:0 overruns:0 frame:0
           TX packets:7615674 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000 
           RX bytes:1595158386 (1.4 GiB)  TX bytes:1485007230 (1.3 GiB)
           Interrupt:4 Base address:0x2000 

eth1       Link encap:Ethernet  HWaddr xxxxxxxx  
           UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
           RX packets:26461 errors:10 dropped:0 overruns:0 frame:5061341
           TX packets:65222 errors:190 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000 
           RX bytes:14372089 (13.7 MiB)  TX bytes:52366007 (49.9 MiB)
           Interrupt:3 Base address:0x1000 

lo         Link encap:Local Loopback  
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
           RX packets:507 errors:0 dropped:0 overruns:0 frame:0
           TX packets:507 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0 
           RX bytes:48684 (47.5 KiB)  TX bytes:48684 (47.5 KiB)

ppp0       Link encap:Point-to-Point Protocol  
           inet addr:109.151.xxxxxxx  P-t-P:217.32.144.166  Mask:255.255.255.255
           UP POINTOPOINT RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:3753951 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3772497 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:3 
           RX bytes:1068104545 (1018.6 MiB)  TX bytes:275444835 (262.6 MiB)

vlan1      Link encap:Ethernet  HWaddr xxxxxxx  
           UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1508  Metric:1
           RX packets:3910813 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3827584 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0 
           RX bytes:341306905 (325.4 MiB)  TX bytes:1105807982 (1.0 GiB)

vlan2      Link encap:Ethernet  HWaddr xxxxxxxx  
           UP BROADCAST RUNNING MULTICAST  MTU:1508  Metric:1
           RX packets:3759430 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3777570 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0 
           RX bytes:1113797945 (1.0 GiB)  TX bytes:373702310 (356.3 MiB)

Code: [Select]

C:\windows\system32>ping -f -l 1472 8.8.8.8

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=64 (sent 1472) time=28ms TTL=44
Reply from 8.8.8.8: bytes=64 (sent 1472) time=25ms TTL=44

Ping statistics for 8.8.8.8:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 25ms, Maximum = 28ms, Average = 26ms
Control-C

hake · « **Reply #1 on:** August 25, 2013, 02:06:10 PM »

I believe that MTU size has implications for packet fragmentation everywhere that your packets might travel via and to. I use a value of 1392, admittedly adopted a few years ago. At the time I found that 1392 practically eliminated packet fragmentation and I have felt no need to change it. The proportion of payload to overhead is small whether MTU is 1392 or 1500 or somewhere in between. I'd far rather minimise fragmentation and have my packets pass unfragmented through whatever routers lie in their path.

Chrysalis · « **Reply #2 on:** August 25, 2013, 07:05:08 PM »

there is no fragmentation, which is the point of what I have done. Unfragmented 1460byte packets. (mss)

any value below 1500 has downsides in that it relies on mtu detection to work well.

http://aa.net.uk/kb-broadband-mtu.html

hake · « **Reply #3 on:** August 25, 2013, 10:52:22 PM »

Thanks. I've followed the link and am reading it.

Further comments: It's a very interesting commentary. Seems to say that you should use MTU of 1500 because some admins cannot configure the network settings of their servers properly. I then went to my BIG FAT BOOK on TCP/IP, The TCP/IP Guide by Charles Kozerierok, which of course deals with how it should work and not how to mitigate the mistakes of others.

I also ran TCPOptimiser and found that pinging www.google.com appeared to necessitate MTU < 1500 to prevent packet fragmentation. I reverted to my very conservative MTU of 1392.

My preference is to reduce fragmentation to piddingly small occurrences and accept a slightly larger overheads to payload ratio than afforded by larger MTU values.

Thanks for pointing me to http://aa.net.uk/kb-broadband-mtu.html. It was a good late night read. Just the thing to print off and take to bed and a stimulating alternative to Father Ted late on Sunday evening. I slept soundly afterwards. Back to Fathers Ted, Jack and Dougal, Mrs Doyle and Bishop Brennan next Sunday night.

Chrysalis · « **Reply #4 on:** August 28, 2013, 02:14:32 AM »

no problem

the net doesnt actually feel alot faster on most sites but i have observed one thing.

previously when I enabled large tcp window sizes the ramp up of speed was occasionally buggy, it would stall or ramp up very slow with large tcp window sizes (on win7/8, thats anything above highlyrestricted autotuning setting), since I have done this change that odd behaviour has stopped. My theory is the autotuning algorithms are possibly buggy with non standard/mainstream mtu sizes.

Alex Atkin UK · « **Reply #5 on:** August 30, 2013, 07:57:07 PM »

I don't understand how this can possibly be working as the MTU will be locked at 1500 in the modem. eg HG612:

Quote

eth0 Link encap:Ethernet HWaddr 1C:1D:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1136775422 errors:0 dropped:0 overruns:0 frame:0
TX packets:1236344754 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3846565565 (3.5 GiB) TX bytes:2594171736 (2.4 GiB)
Interrupt:40 Base address:0x6a00

eth0.4 Link encap:Ethernet HWaddr 1C:1D:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:113760808 errors:0 dropped:0 overruns:0 frame:0
TX packets:142783826 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1021250542 (973.9 MiB) TX bytes:3587799499 (3.3 GiB)

eth0.5 Link encap:Ethernet HWaddr 1C:1D:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1023014614 errors:0 dropped:0 overruns:0 frame:0
TX packets:1093560928 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2825315023 (2.6 GiB) TX bytes:3301339533 (3.0 GiB)

ptm1 Link encap:Ethernet HWaddr 1C:1D:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1405447455 errors:13942 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:183599694 (175.0 MiB)

ptm1.10 Link encap:Ethernet HWaddr 1C:1D:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1078602619 errors:0 dropped:0 overruns:0 frame:0
TX packets:985781030 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2048009670 (1.9 GiB) TX bytes:1490784597 (1.3 GiB)

Also bearing in mind my Digital Region connection reports:

Quote

TCP options string = 020405840402080a05b9eafc0000000001030307
MTU = 1452
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
MSS = 1412
MSS is not optimized for broadband. Consider increasing your MTU value.
Default TCP Receive Window (RWIN) = 14208
RWIN Scaling (RFC1323) = 7 bits (scale factor: 2^7=128)
Unscaled TCP Receive Window = 111

Yet I get 90/30 on my 99/35 synced connection. So is it really worth all this hassle?

Chrysalis · « **Reply #6 on:** August 31, 2013, 09:33:11 AM »

dont bother if you feel it isnt worth it for you, some of us prefer a 1500byte MTU. But its not essential.

you can clearly see it works from my pics in first post.

the hg612 is only a bridge not the ppp endpoint.

what are you doing with a 99/35 sync when FTTC is capped aty 80/20 and I am unware of any FTP service at that spec.

Also your mtu is below even pppoe spec no idea why you using 1452. you even in the uk?

Alex Atkin UK · « **Reply #7 on:** August 31, 2013, 05:49:45 PM »

I'm on the ill-fated Digital Region network, which sadly means unless BT change their policy I will be downgraded to 80/20 when I am migrated over to BT.

Yes the HG612 is a bridge, which means you are still limited by its TCP/IP configuration. It operates with a 1500 MTU which I believe means you not only have to take off the PPP overhead but you also have to take off the VLAN tagging overhead, used on the backhaul network. I could be wrong about that, but it makes sense that if you don't it will still have to fragment the PPP packets unless the backhaul is using jumbo frames (and the HG612 implies it is not).

As for my connection, ignore what it said above it was a configuration error on the PC I was using. I now have my MTU back to 1480 network wide which AFAIK is what it should be for a PPPoE driven connection.

Chrysalis · « **Reply #8 on:** August 31, 2013, 08:58:04 PM »

I just checked my hg612 and is various interfaces with a mtu value of 0 or 16000, I think those are used for the bridging. I am only guessing but there is no way my packets are been shrunk by the hg612 otherwise It would be present in my end to end tests.

Also for pppoe normal MTU is 1492 not 1480. As it has a 8 bytes overhead.

Alex Atkin UK · « **Reply #9 on:** August 31, 2013, 09:33:15 PM »

Nope, the Internet connection runs over PTM and guess what MTU it uses:

Quote

ptm1.10 Link encap:Ethernet HWaddr 1C:1D:67
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1118851629 errors:0 dropped:0 overruns:0 frame:0
TX packets:1022187900 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2508399028 (2.3 GiB) TX bytes:4230861243 (3.9 GiB)

If the link to the backhaul is only 1500 and it has to carry the PPP and VLAN tagging overheads, I just don't see how your configuration can possibly be working properly. As to why it would appear its working I can only guess that the HG612 is fragmenting the packets and recombining them in such a way its invisible to the PPP link itself? I don't know enough about networking to know if that is possible or not but it would be far from optimal.

I have seen a few reports that you should use an MTU of 1480 for PPPoE and that seems to be set automagically for me on OpenWRT even though I can see in the code the default is 1492. I assume its being corrected by the PPP server as it knows its on a network using VLAN tagging so 1492 would be too high. However that should equally apply to BTs network as the only thing I had to change on the HG612 to make it work on Digital Region was change the VLAN ID (and disable QoS so its managed by my router).

Although, this muddies the water somewhat:

Quote

Since Ethernet has a maximum payload size of 1500 octets, and the
PPPoE Header plus Protocol ID is 8 octets, an MRU greater than 1492
can only be accommodated if the negotiating devices, and any
intermediate devices, are capable of treating the PPPoE Header plus
Protocol ID as if they were part of the Ethernet Header. In other
words, they must have sufficient overhead in their Ethernet Header
representations to accommodate the extra 8 octets.

Devices that are not capable of handling the extra 8 octets in their
Ethernet Header SHOULD negotiate an MRU no larger than 1492. If no
MRU has been specified by the receiving side, the sending side MAY
assume that the receiving side is capable of handling the PPP default
MRU of 1500. To ensure compatability with older equipment, if the
sending side is assigning an MRU greater than 1492 to the receiving
side, (either by default, or through negotiation), it is RECOMMENDED
that the sending side send one or more MRU-sized Echo-Request packets
once the session is opened, to test that the receiving side and any
intermediate equipment can handle the MRU. If no Echo-Replies are
received, the sending side MAY choose to repeat the test with
Echo-Request packets of size 1492. If these packets receive replies,
the sending side MAY choose to treat the receiver as if it had
explicitly specified an MRU of 1492.

If the LCP includes any 802.1Q VLAN tags, a device SHOULD negotiate
an MRU no larger than 1492."

But even there, that involves leaving the MTU at 1500 NOT increasing it is 1508.

Chrysalis · « **Reply #10 on:** September 01, 2013, 10:53:37 AM »

Alex be aware there is a lot of misinformaiton out on the net, yes people will be spouting all sorts of figures.

If this wasnt working I say it again I would be seeing fragmented packets, the ping command I pasted was non fragmented packets and the speedguide test reporting the non fragmented packet size also.

Also people on tbb have replied to me I posted same guide there) and they thanked me as well as confirming they have it working fine. AAISP is run by some very clever people I posted an article they written on this thread.

Also this works on the homehub as well, that uses the same trick to get 1500 byte mtu on BT's FTTC service.

http://wiki.aa.org.uk/FTTC_Modem
http://wiki.aa.org.uk/Router_-_RouterOS_and_Routerboard

Quote

The BT VDSL2 modem supports using baby jumbo frames of 1508 bytes so the PPP payload is now 1500 bytes which is the same as regular Ethernet.

Alex Atkin UK · « **Reply #11 on:** September 01, 2013, 03:23:42 PM »

Thanks for the links, I will definitely look into it. I'm still puzzled how it can possibly be working when the modem MTU is 1500, but I guess it must be if so many people are adamant it is.

Chrysalis · « **Reply #12 on:** September 02, 2013, 01:12:41 AM »

I agree your points have raised questions and have myself tried to find an explanation.

My router did self reboot yesterday and it doesnt auto connect at MTU 1500 of its own accord which is annoying, but even more annoying is the router instability I now need to fix.

One of the people said it broke 2 sites he is using, I have asked for those sites so I can test myself. Everyone else says its humming along nicely.

Chrysalis · « **Reply #13 on:** April 20, 2015, 10:09:14 PM »

a further update to this old thread.

merlin's version of asuswrt now has 1500mtu pppoe support built in (can be configured just in the GUI, it will do all the jumbo frame stuff for you automatically).

However I had to turn it off as was causing issues for me on ipv6. As far as I am aware all of ipv4 was fine.

Alex Atkin UK · « **Reply #14 on:** April 20, 2015, 10:31:30 PM »

It still makes no sense how its managing to fit 1500 bytes plus PPP overhead into 1500 bytes. Its sorcery I tells ya!

News:

Author Topic: 1500 byte MTU on FTTC, possible. (Read 21678 times)

Chrysalis

1500 byte MTU on FTTC, possible.

hake

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

hake

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

Alex Atkin UK

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

Alex Atkin UK

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

Alex Atkin UK

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

Alex Atkin UK

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

Chrysalis

Re: 1500 byte MTU on FTTC, possible.

Alex Atkin UK

Re: 1500 byte MTU on FTTC, possible.