Register (or login) on our website and you will not see this ad.
|
|
Hi, just thought I would share this, if your a talktalk customer and using the supplied router the default MTU is 1500, I purchased a Netgear D7000 the default on the router is 1500, I was reading the talktalk help pages and noticed that if using your own router to try MTU 1432 download went from 58 to 68.
Kev
BlueBoy was here heheh
|
|
|
TalkTalk routers are supplied at MTU 1432 for ADSL. The network fully supports MTU 1492 though, and that is the optimum. Any MTU value above 1492 should be avoided due to packet fragmentation (TalkTalk routers will not allow any value above 1492).
Oliver.
|
|
|
Hi Oliver341
Now not so sure it was the MTU as reset MTU back to 1500 and no difference, may have been the new router increased the speed at the same time I was toying with the MTU.
Do you think it may have nudged something to get that speed increase ?
Kev
BlueBoy was here heheh
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Not sure. If your router is currently set to MTU 1500, can you paste the results of this:
ping -f -l 1472 bbc.co.uk
Oliver.
|
|
|
Hi Oliver341
Appears to be a Netgear thing , thank you for the help.
Pinging bbc.co.uk [212.58.244.22] with 1472 bytes of data:
Reply from 192.168.0.1: Packet needs to be fragmented but DF set.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 212.58.244.22:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
BlueBoy was here heheh
|
|
|
No problem. As expected, MTU 1492 is the optimum value.
Oliver.
|
|
|
The optimum & max. MTU for Fibre (from your speeds) is 1492. 1500 is only for ADSL over PPPoA.
1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 20 Meg WBC
|
|
|
Thank You
BlueBoy was here heheh
|
|
|
The optimum & max. MTU for Fibre (from your speeds) is 1492. 1500 is only for ADSL over PPPoA.
The MTU on TalkTalk PPPoA (ADSL) can only go up to 1492 before fragmentation occurs, so it's slightly different to PPPoA on ADSL over Sky and BT which can achieve 1500.
PPPoE on fibre as you say is 1492 max on any provider, but since Sky use DHCP on fibre they can use MTU 1500.
Oliver.
Edited by Oliver341 (Mon 08-Feb-16 23:40:11)
|
|
|
PPPoE on fibre as you say is 1492 max on any provider, but since Sky use DHCP on fibre they can use MTU 1500.
Not true. With hardware and software that supports RFC 4638, MTU 1500 is possible over PPPoE. This post comes to you over a connection to Zen with MTU 1500 (HG612, pfSense 2.3.2 running on a box with a jumbo capable Ethernet interface used for the link to the HG612, MTU 1500 configured on the pfSense WAN interface).
|
|
|
PPPoE on fibre as you say is 1492 max on any provider, but since Sky use DHCP on fibre they can use MTU 1500.
Not true. With hardware and software that supports RFC 4638, MTU 1500 is possible over PPPoE. This post comes to you over a connection to Zen with MTU 1500 (HG612, pfSense 2.3.2 running on a box with a jumbo capable Ethernet interface used for the link to the HG612, MTU 1500 configured on the pfSense WAN interface).
I am with Zen FFTC and using a Draytek 2860 with firmware 3.8.2.3_BT. This thread prompted me to see what my MTU was set at and found it to be 1520.
My speed test result is:shown below and I am some considerable distance from the cabinet:
http://www.thinkbroadband.com/speedtest/results.html...
Would there be any benefit if I reduced the MTU size?
Please be aware that I have a sure signal device connected to the network which is working just fine. These units can cause a lot of grief to connect to the Vodafone service and I wouldn't wish to have a different MTU affecting its operation.
Some DSL information provided by the router is listed below
ATU-R Information
Type: VDSL2
Hardware: Annex A
Firmware: 05-07-06-0D-01-07
Power Mngt Mode: DSL_G997_PMS_L0
Line State: SHOWTIME
Running Mode: 17A
Vendor ID: b5004946 544e0000
ATU-C Information
Vendor ID: b5004244 434da48c [BDCM]
Line Statistics
Downstream
Actual Rate 11813 Kbps
Attainable Rate 12285 Kbps
Path Mode Fast
Interleave Depth 1
Actual PSD 11. 8 dB
SNR Margin 7 dB
Attenuation 35 dB
Upstream
Actual Rate 1110 Kbps
Attainable Rate 1109 Kbps
Path Mode Fast
Interleave Depth 1
Actual PSD 7. 8 dB
SNR Margin 6 dB
Attenuation 15 dB
Thanks for reading this and I look forward to any comments received.
|
|
|
With hardware and software that supports RFC 4638, MTU 1500 is possible over PPPoE. This post comes to you over a connection to Zen with MTU 1500 (HG612, pfSense 2.3.2 running on a box with a jumbo capable Ethernet interface used for the link to the HG612, MTU 1500 configured on the pfSense WAN interface).
To demonstrate (using a FreeBSD 10.3 box at a root privileged shell):
| Bash | 1
23
45
67
89
1011
1213
1415
1617
1819
20 | [root@manganese ~]# ping -D -s 1472 -c 4 forum.pfsense.org
PING forum.pfsense.org (208.123.73.18): 1472 data bytes1480 bytes from 208.123.73.18: icmp_seq=0 ttl=49 time=115.066 ms
1480 bytes from 208.123.73.18: icmp_seq=1 ttl=49 time=115.006 ms1480 bytes from 208.123.73.18: icmp_seq=2 ttl=49 time=115.137 ms
1480 bytes from 208.123.73.18: icmp_seq=3 ttl=49 time=115.057 ms
--- forum.pfsense.org ping statistics ---4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 115.006/115.067/115.137/0.047 ms[root@manganese ~]# ping6 -D -s 1452 -c 4 forum.pfsense.org
PING6(1500=40+8+1452 bytes) [censored] --> 2610:160:11:1000::181460 bytes from 2610:160:11:1000::18, icmp_seq=0 hlim=50 time=138.622 ms
1460 bytes from 2610:160:11:1000::18, icmp_seq=1 hlim=50 time=138.636 ms1460 bytes from 2610:160:11:1000::18, icmp_seq=2 hlim=50 time=138.652 ms
1460 bytes from 2610:160:11:1000::18, icmp_seq=3 hlim=50 time=138.684 ms
--- forum.pfsense.org ping6 statistics ---4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 138.622/138.649/138.684/0.023 ms |
In line 1, I run IPv4 ping against a host that responds with a full-size payload, asking for no fragmentation, a 1472 byte payload (which, with 8 bytes ICMP overhead and 20 bytes IPv4 overhead, is 1500 bytes total), and 4 packets to be sent. The host responds in lines 3-6 with 1480 bytes (1500 bytes with the 20 byte IPv4 overhead).
In line 6, I run IPv6 ping against a host that responds with a full-size payload, asking for no fragmentation, a 1452 byte payload (which, as explained in line 13, is 1500 bytes total when you add the 8 byte ICMPv6 overhead and 40 byte IPv6 overhead) and 4 packets to be sent. The host responds in lines 13-16 with 1460 bytes (1500 bytes with the 40 byte IPv6 overhead).
|
|
|
I am with Zen FFTC and using a Draytek 2860 with firmware 3.8.2.3_BT. This thread prompted me to see what my MTU was set at and found it to be 1520.
Zen FTTC supports RFC 4638 with suitable hardware and software, as in my system.
RFC 4638 would allow MTU 1520, but BT SIN 498 states in R.ETH1 at the bottom of page 28 that "Support for
frame sizes above 1534 bytes (inclusive of C-VLAN) is not guaranteed."
1534 bytes, less the 18 byte Ethernet overhead and the 4 byte overhead for the C-VLAN 802.1q tag is 1512 bytes. This is 4 bytes greater than the 1508 bytes needed for MTU 1500 over PPPoE (1500 + 8 byte PPPoE overhead). I presume that 1534 was adopted as the GEA wide requirement because of the option of using double tagging (needing 4 additional bytes for the S-VLAN 802.1q tag) on the GEA CableLink between Openreach and the CP / BT Wholesale. I would not be surprised if Openreach GEA-FTTx fails to work with a PPPoE MTU of more than 1500, though I can't trivially check, as there appears to be a hard-coded limit of 1500 in the mpd5 daemon used by FreeBSD and pfSense.
In any event, a PPPoE MTU greater than 1500 is of limited use, as the Ethernet standard only supports 1500 bytes. Anything larger requires jumbo frames, which not all switches and endpoints support.
Even though your MTU appears to be set to 1520, I would be surprised if a PPPoE MTU of greater than 1500 is in use. 1500 is ideally what you want, as it should prevent fragmentation in either direction, which should prevent problems with Vodafone Sure Signal devices.
If incoming ping is enabled on your WAN address, letmecheck.it MTU test will figure out your WAN MTU. Your local devices are almost certainly set to MTU 1500 unless you have taken steps to configure an explicit lower MTU.
None of the diagnostics you give show anything about the MTU.
Would there be any benefit if I reduced the MTU size?
To avoid unnecessary fragmentation and the possibility of MTU related blackholes, MTU 1500 is ideal. If your system doesn't support RFC 4638, MTU 1492 is the maximum achievable and the next best thing.
|
|
|
I am with Zen FFTC and using a Draytek 2860 with firmware 3.8.2.3_BT. This thread prompted me to see what my MTU was set at and found it to be 1520.
Zen FTTC supports RFC 4638 with suitable hardware and software, as in my system.
RFC 4638 would allow MTU 1520, but BT SIN 498 states in R.ETH1 at the bottom of page 28 that "Support for
frame sizes above 1534 bytes (inclusive of C-VLAN) is not guaranteed."
1534 bytes, less the 18 byte Ethernet overhead and the 4 byte overhead for the C-VLAN 802.1q tag is 1512 bytes. This is 4 bytes greater than the 1508 bytes needed for MTU 1500 over PPPoE (1500 + 8 byte PPPoE overhead). I presume that 1534 was adopted as the GEA wide requirement because of the option of using double tagging (needing 4 additional bytes for the S-VLAN 802.1q tag) on the GEA CableLink between Openreach and the CP / BT Wholesale. I would not be surprised if Openreach GEA-FTTx fails to work with a PPPoE MTU of more than 1500, though I can't trivially check, as there appears to be a hard-coded limit of 1500 in the mpd5 daemon used by FreeBSD and pfSense.
In any event, a PPPoE MTU greater than 1500 is of limited use, as the Ethernet standard only supports 1500 bytes. Anything larger requires jumbo frames, which not all switches and endpoints support.
Even though your MTU appears to be set to 1520, I would be surprised if a PPPoE MTU of greater than 1500 is in use. 1500 is ideally what you want, as it should prevent fragmentation in either direction, which should prevent problems with Vodafone Sure Signal devices.
If incoming ping is enabled on your WAN address, letmecheck.it MTU test will figure out your WAN MTU. Your local devices are almost certainly set to MTU 1500 unless you have taken steps to configure an explicit lower MTU.
None of the diagnostics you give show anything about the MTU.
Would there be any benefit if I reduced the MTU size?
To avoid unnecessary fragmentation and the possibility of MTU related blackholes, MTU 1500 is ideal. If your system doesn't support RFC 4638, MTU 1492 is the maximum achievable and the next best thing.
Thank you for your response. Lowering my router protection for the purpose of the test my results are shown below. I now propose to set my MTU at 1500 and hope in doing so the Sure Signal Device will continue to work. Will post back the status. My true IP address is not shown here.
Sending 32 bytes to 99.99.99.99 <- not fragmented
Sending 750 bytes to 99.99.99.99 <- not fragmented
Sending 1125 bytes to 99.99.99.99 <- not fragmented
Sending 1313 bytes to 99.99.99.99 <- not fragmented
Sending 1407 bytes to 99.99.99.99 <- not fragmented
Sending 1454 bytes to 99.99.99.99 <- not fragmented
Sending 1478 bytes to 99.99.99.99 <- FRAGMENTED!
Sending 1466 bytes to 99.99.99.99 <- not fragmented
Sending 1472 bytes to 99.99.99.99 <- not fragmented
Sending 1475 bytes to 99.99.99.99 <- FRAGMENTED!
Sending 1473 bytes to 99.99.99.99 <- FRAGMENTED!
Sending 1472 bytes to 99.99.99.99 <- not fragmented
From the tests we did, we can assume that 1472 bytes is the largest unfragmented packet
size. The MTU size would be 1500, made up from 1472 payload and 28 ICMP/IP Headers
and payload information.
The maximum MTU size for 99.99.99.99 is: 1500
NB: The Internet Protocol requires that hosts must be able to process IP datagrams of at least
576 bytes (for IPv4) or 1280 bytes (for IPv6)
|
|
|