In reply to a post by David_W:

In reply to a post by Oliver341:

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).

In reply to a post by David_W:

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).

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 reply to a post by trolleybus:

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.

In reply to a post by trolleybus:

Would there be any benefit if I reduced the MTU size?

In reply to a post by David_W:

In reply to a post by trolleybus:

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.

In reply to a post by trolleybus:

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.