MTU Setting

[#1]

---

---

I would like to know whether it really the case, that the MTU can't be altered, because if it can't then network MTU discovery (by other devices on the LAN) will be a disaster if the default MTU happens to cause fragmentation on a customers internet connection.

I'm not sure it would normally matter. If the router is hard-coded to a value that is too large for the WAN side it would be a disaster but that's clearly not the case. So all we're left with is a router that may be hard-coded to a smaller than needed MTU. Any LAN side testing will discover and use this value. There will be a slight performance degradation in that situation but probably not very much.

It'll only matter if/when the DNF flag is set. My guess is that PSN is sending packets with that set and that's the problem. If I'm right then Sony software developers need a good old-fashioned [-Censored-] kicking (again). Packet fragmentation does have some performance impact and does put extra load on routers but neither is very significant in the grand scheme of things. I don't believe it's necessary for PSN to be setting that flag.

Edit I've found a few articles suggesting that PSN might be padding packets as part of their DDOS mitigation strategy. That may cause previously valid packet sizes to become too large. If that's the case you don't want to pick the highest possible MTU, but rather one with 'room to grow'.

[#2]

---

@Anotherone wrote:

I'd rather hear it from the horse's mouth, so to speak.

---

Whatever you say !

[#3]

I take it that's you on the RHS   Now having taken this thread right off-topic, I think we'd better behave!

[#4]

My Vigor 2925 has an MTU discovery feature that for my lines came up with 1492 I know it's not standard (or is it?) but at least I have the ability to change it. Can't the change be applied using a telnet session on the likes of the HH5B / 2704n?

[#5]

All in all if you fancy giving Sony software developers an [-Censored-] kicking you're in good company. Like pretty much all hardware developers their software generally sucks. Comes from it not being seen as a revenue stream. Indeed with free updates being released software is most often seen as a loss leader.

[#6]

---

@Anotherone wrote:

I take it that's you on the RHS

---

Neigh !  

[#7]

---

@Anotherone wrote:

Well the HH5B is 1492, the 2704n is 1492, I'm baffled as to why the Hub One should be different - rebadged HH5A but with Plusnet skinning and some minor changes like no BT WiFi hotspot. Whilst I accept it might be different, I'd rather hear it from the horse's mouth, so to speak.

---

AFAIK, MTU on the Hub One in ADSL mode is set to 1500. For VDSL, I'm not so sure and I've struggled to find an answer from anybody in the office.

Testing via command line does suggest the maximum reliable packet size to be 1460 minus overheads (so 1488 total):

>ping www.yahoo.com -f -l 1462

Pinging fd-fp3.wg1.b.yahoo.com [46.228.47.115] with 1462 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 46.228.47.115:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

>ping www.yahoo.com -f -l 1460

Pinging fd-fp3.wg1.b.yahoo.com [46.228.47.115] with 1460 bytes of data:
Reply from 46.228.47.115: bytes=1460 time=98ms TTL=52
Reply from 46.228.47.115: bytes=1460 time=44ms TTL=52
Reply from 46.228.47.115: bytes=1460 time=96ms TTL=52
Reply from 46.228.47.115: bytes=1460 time=53ms TTL=52

Must admit, that would be a tad odd though. An inbound test here gives me a slightly more expected response (note that the ICMP response is being provided by a Raspberry Pi sat in the DMZ behind the router):

Sending 32 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 750 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1125 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1313 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1407 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1454 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1478 bytes to 143.159.XXX.XXX  <-  FRAGMENTED!

Sending 1466 bytes to 143.159.XXX.XXX  <-  FRAGMENTED!

Sending 1460 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1463 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1465 bytes to 143.159.XXX.XXX  <-  FRAGMENTED!

Sending 1464 bytes to 143.159.XXX.XXX  <-  not fragmented

Sending 1465 bytes to 143.159.XXX.XXX  <-  FRAGMENTED!

Sending 1464 bytes to 143.159.XXX.XXX  <-  not fragmented

From the tests we did, we can assume that 1464 bytes is the largest unfragmented packet
size. The MTU size would be 1492, made up from 1464 payload and 28 ICMP/IP Headers
and payload information. 

Make what you will of that.

[#8 · Accepted solution]

Hey all,

Just setting up the Netgear D6400 and it's looking good so far...

« SpeedGuide.net TCP Analyzer Results »
Tested on: 2016.05.03 13:09
IP address: 146.198.xxx.xxx
Client OS/browser: Windows 10 (Firefox 45.0)

TCP options string: 020405ac0103030801010402
MSS: 1452
MTU: 1492
TCP Window: 66560 (NOT multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 260
Recommended RWINs: 63888, 127776, 255552, 511104, 1022208
BDP limit (200ms): 2662kbps (333KBytes/s)
BDP limit (500ms): 1065kbps (133KBytes/s)
MTU Discovery: ON
TTL: 51
Timestamps: OFF
SACKs: ON
IP ToS: 10000000 (128)
Precedence: 100 (flash override)
Delay: 0 (normal delay)
Throughput: 0 (normal throughput)
Reliability: 0 (normal reliability)
Cost: 0 (normal cost)
Check bit: 0 (correct)
DSCP (DiffServ): CS4 100000 (32) - class 4 (RFC 2474). Similar forwarding behavior to the ToS Precedence field.

It says my MTU is optimized whereas before it said "somewhat" optimized

Edit: Packets don't fragment at 1464 now instead of before at 1440

Also the IP fragment message is no longer there on the PS Vita, gonna fire up the PS3 now to confirm it's the same and that I can connect to game when it wasn't before.

Yup IP fragment message gone from all devices , connected to game no problem.

Guess Sony doesn't like the HH5a and Hub One's locked MTU of 1488

[#9]

---

@Anonymous wrote:

My Vigor 2925 has an MTU discovery feature that for my lines came up with 1492 I know it's not standard (or is it?) but at least I have the ability to change it. Can't the change be applied using a telnet session on the likes of the HH5B / 2704n?

My understanding was that the FTTC PPPoE MTU over the BT network (ie wasn't LLU) was 1492 so the last two responses are interesting.

Neither of the HH's, Hub One or 2704n cab be accessed by Telnet.

---

[#10]

---

@Anotherone wrote:

---

Neither of the HH's, Hub One or 2704n cab be accessed by Telnet.

---

---

[-Censored-]!

[#11]

It is [-Censored-]. Nor can they be set to respond to Pings so TBB BQMs are out

[#12]

What a crock of brown stuff, honestly. Maybe best to invest in some decent hardware.

[#13]

1492 is "normal" for pppoe, but Openreach/BTW/Plusnet will allow 1500 over pppoe (mini jumbos) - I am using them currently.

I use an ECI modem and a little DC PC as a router so that does the pppoe.

Historically pppoe was 1492 as it has an overhead of 8 which takes it to the old ethernet limit of 1500.

That limit is not so strict with more modern nics.

[#14]

---

@Anotherone wrote:

My understanding was that the FTTC PPPoE MTU over the BT network (ie wasn't LLU) was 1492

---

Well your understanding would be wrong ! - although that is a common misconception.

The BT FTTC network MTU is actually 1500.

If you have a decent router that can support "baby jumbo frames" on it's WAN connection, and a compatible VDSL modem, then is IS possible to run a router connected via PPPoE to a modem with the full 1500 MTU on a BT fibre connection.

1492 is commonly thought to be the PPPoE MTU maximum, because that is the limitation found on legacy consumer grade equipment.

Did I mention you needed to have a decent/modern router ?  LOL !

[#15]

---

legume wrote:

That limit is not so strict with more modern nics.;

---

Modern gigabit NICs often support "jumbo frames" which can operate an MTU of up to 9000.