MTU setting for Zen via CityFibre

I was wondering what the recommended MTU is for Zen users using our own modems via CityFibre. I've currently got it set to 1492 which is what I was using previously with my old FTTC connection however I'd read somewhere that CityFibre supports a larger MTU but before I go fiddling and breaking things I thought I'd ask here in case someone had some good advice.

Hi

Found an posting online that says the MTU can be set to 1508, so basically 1500 with the 8 bytes overhead for pppoe.

Regards

Andrew

I am not connected to CityFibre yet (iam awaiting one last connection from Zen before they can offer CityFibre to me yet)

I did a little looking around while I was waiting and saw two useful sources of info:

https://cdn.cityfibre.com/Partner-page/Downloads/CF-...

https://support.aa.net.uk/CityFibre_ONT

Both Suggest the Max MTU for CF is 1900, Hopefully Zen will support this too!

I tried to set 1900 on my Asus RT-AX86U but it only let me set up to 1492 (On Zen/CF)

In reply to a post by RichTea23:

Both Suggest the Max MTU for CF is 1900, Hopefully Zen will support this too!

The Internet in general does not run at 1900 MTU so no don't bother trying that.
1500 is still the correct size for layer 3 on a router.

1508 is mostly a special PPPoE use case between a router's ethernet interface and an xDSL modem (ADSL or FTTC) so that the PPP encapsulation is able to accommodate 1500 inside it.

If your FTTP also uses a PPPoE that's where you'd need to be sure the intervening connectivity to the provider supports 1508 until the PPPoE is decapsulated.
(With xDSL this happens before it even leaves your property as it goes out on the telephone cable twisted pair rather than as ethernet).

Other higher MTUs are really only viable for use within inside the LAN and only if you know you have at least 2 devices that can support it. Enterprises and other organsiations with multiple internal routers may also be able to route > 1500 internally if they know it is possible on their kit.

Edited by prlzx (Wed 14-Feb-24 21:53:37)

In reply to a post by timo_w2s:

I was wondering what the recommended MTU is for Zen users using our own modems via CityFibre. I've currently got it set to 1492 which is what I was using previously with my old FTTC connection however I'd read somewhere that CityFibre supports a larger MTU but before I go fiddling and breaking things I thought I'd ask here in case someone had some good advice.

1500 is the maximum anyone should be setting for the internet.
1492 is used because 8 bytes are used on PPPoE.

With Openreach FTTC and with PPP I used to set 1508 on specific interfaces on the router as that was 1500 + 8 for PPP, but the modem needed to support RFC 4638 (baby jumbo frames).

Some will say Cityfibre uses higher MTU because they make the incorrect assumption that some Cityfibre providers don't use PPP so it saves 8 bytes.
Well some Cityfibre providers DO use PPP, just as some Openreach providers DON'T.

If it's the same router you used 1492 with before then use 1492 again.

Zen's preferred router is the Fritz!Box. On the AVM website I found this:

Adjusting the MTU size in the FRITZ!Box

The FRITZ!Box does not offer the option to manually adjust the MTU size (Maximum Transmission Unit), i.e. to manually set the maximum size of user data that can be transmitted in a single data packet.

Manually adjusting the MTU size is also not necessary because the FRITZ!Box supports MSS clamping (Maximum Segment Size) that automatically adjusts the size of the data packets to the smaller MTU of the interconnected networks.

This means that there will be no performance loss due to the fragmenting or discarding of data packets.

Note:The maximum MTU is 1492 bytes for DSL connections established via PPPoE (Point to Point Protocol over Ethernet). The maximum MTU is 1500 bytes for cable and fiber optic connections. The internet service provider can reduce the MTU by using additional protocols.

In reply to a post by cjn:

Note:The maximum MTU is 1492 bytes for DSL connections established via PPPoE (Point to Point Protocol over Ethernet). The maximum MTU is 1500 bytes for cable and fiber optic connections. The internet service provider can reduce the MTU by using additional protocols.

And that's plain wrong from Fritzbox.

Openreach fully support RFC 4638 and so do many modems and routers. I ran a 1508 MTU (1500 after PPP is stripped) for years on FTTC.
I modified my Zyxel firmware to support it in bridge mode. Many others run the same kind of setup.

The Openreach Huawei Hg612 supported it, and A&A even advised you to set 1508 in your router.

AFAIK all the Openreach ONTs support it, my Huawei does.

Cityfibre support it also.

Here's a post where someone claims to have patched a Fritzbox 7530 to support 1508 MTU on PPP. It's recent and doesn't look tested.

In reply to a post by j0hn83:

And that's plain wrong from Fritzbox.

One of the downsides of using AVM's boxes is they are designed and engineering for the German market. Their statement may be correct for German DSL services, but is incorrect for Openreach DSL in the UK.

Since I know nothing and care less about MTU, I'll just return to my state of blissful ignorance and leave the experts to their debate.

Thanks for all the comments. I may try setting the MTU to 1508 and see what happens. I'll post back here if I do. I'm just a bit cautious as the router has two LAN-LAN VPN connections and a couple of dial-in VPN users but nothing mission critical.

Personally I would just leave it at the default. Any potential througput increase is going to be negligible (1% at most) but the decrease if it causes fragmentation is going to be much greater.

Whatever approach you try make sure you are only changing the MTU on the WAN ethernet interface so that your LAN interfaces stay on the default 1500.

Also check if you can find the MSS clamping option in your router.
The default behaviour should be applying it only to connections which will require the outgoing WAN interface
with TCP MSS automatically set to MTU-40 (IPv4, 1460) and MTU-60 (IPv6, 1440).

As I mentioned before the intended result is 1508 MTU on the WAN ethernet interface and 1500 MTU on the inside of the PPP interface (of PPPoe).

You can test the outcome with options on a PING command, example for Windows:

ping 1.1.1.1 -f -l 1472

where this requests to send an un-fragmentable (DF) packet that will completely fill the 1500 MTU.
1472 should succeed while
1473 should receive the standard error: "Packet needs to be fragmented but DF set."

Your VPN connections should already be allowing for overhead and their virtual interfaces will have their own smaller MTU typcially in a range 1400 (e.g. IPSec) to1420 (e.g. Wireguard).

Edited by prlzx (Mon 19-Feb-24 13:23:21)

I'm not actually too interested in the potential throughput increase as I'm pretty happy with my speed right now, although that would be a bonus. I want to try a larger MTU because I have a cheap Netgear managed switch (GS308E) which I can't connect to when I'm accessing it via a remote VPN tunnel. After a lot of head scratching and googling I found a comment someone made about the very basic IP stack on the switch's micro controller is not able to handle a smaller MTU than the default so I thought I would try and see if the MTU change on the router would resolve my issue.

I have already been using another GS308E switch at a remote location for a few years and has always worked just fine over a VPN connection so I never even thought there would be an issue when I got another one to use here, but after a bit of poking around I noticed that that other router had an MTU of 1500 via a 4G connection and thought maybe that's why it works.

However, if my VPN connections already allow for overheads and lower MTUs then I'm not sure why the other switch works through a VPN.

If the switch responds to PING, you can use it as the target of a DF PING (as per previous post) from remote when coming back in over VPN to determine what size it replies to.

(Start from max PING payload of 1472 and some arbitrarily smaller values, e.g. 1372, 1252 see if it replies).

However if it only replies to requests from the local subnet that can be a sign of the default gateway being missing from the switch's IP configuration.
One way to check is if the switch can even see the Internet assuming it has diagnostic tools for ping and traceroute built-in?

Edited by prlzx (Mon 19-Feb-24 21:34:59)