Zen and RFC 4638 Baby Jumbo Frames

Sadly, Zen has dropped support for RFC 4638 as of a week or so ago.

I know this for sure on ADSL, not too sure about Fibre.

I had an email from Zen confirming there will be an "upgrade" and as such my internet may wobble for a bit about a couple of weeks ago, since then my router will not use RFC 4638. Setting it by force causes packet loss.

Called Zen's technical team earlier and confirmed they have dropped RFC 4638.

No idea why they would downgrade their service in this way. I asked if they would ever switch it back on and they said no.

Shame...

I am posting this to stop anyone spending hours messing with OpenWRT wondering why they can't get this functionality working. Its them, not you

Is this on Zens own backhaul only or also on BT?

Interesting, I don't currently use baby jumbo frames but I had considered trying it out as I imagine my EdgeRouter would do this if I wanted it to (via HG612). If FTTC also has lost this (via Zen's back-haul) then I won't be ever trying that for the remainder of the contract term.

Hi,

I don't post here too often as my colleague Andy has been picking things up - but I've just noticed this thread. I'll take a look into this and post back.

Cheers,

Jon

In reply to a post by rlees85:

Sadly, Zen has dropped support for RFC 4638 as of a week or so ago.

I know this for sure on ADSL, not too sure about Fibre.

I guess if you need passthrough from something pretending to be a modem or Zen are "special" for ADSL then fair enough, but ...

Why would anyone in normal setups be using pppoe(oa) on adsl anyway.
pppoa vcmux is more efficient and should be OK at 1500 MTU without anything special needed.

Edit: Though with adsl pppoe vc mux running 1478 MTU or MSS clamp is slightly more efficient than 1500.

Edited by deleted (Mon 09-Oct-17 23:42:10)

It is using BTs backhaul, be great of Zen do change their mind...

I'm not an expert in MSS/Clamping but I am sure that PPPoA is supposed to be even more inefficient than PPPoE with standard 1492.

In reply to a post by rlees85:

It is using BTs backhaul, be great of Zen do change their mind...

I'm not an expert in MSS/Clamping but I am sure that PPPoA is supposed to be even more inefficient than PPPoE with standard 1492.

MSS clamping is a bit OTT unless you know iptables. If you are using a MTU < 1500 your router will probably do it for you.

On ADSL pppoe isn't just pppoe as it is on FTTC, it's still got to go over aal5 and ATM which means it's at least 22 bytes per packet more fixed overhead than pppoa vc multiplex.
Depending on packet size there will be some additional variation for both as AAL5 pads out to fit a whole number of ATM cells, but for ADSL it is less efficient.

Interesting.... ISPs and BT are never that forthcoming with technical details like that. Last time I checked people seemed to recommend PPPoE even on ADSL connections but after another look around it seems you are right and generally all ADSL stuff goes over ATM anyway.... thanks for the info

Are you sure your information applies to 21CN?

The 21CN network was built from the start to support PPPoE and this is actually the preferred connection method but they also detect and support any PPPoA connections for backwards compatibility.

Edited by deleted (Wed 11-Oct-17 16:51:55)

Source for quote?

I guess there is scope for confusion, but AFAIK 21cn is ethernet based teleco side and 20cn was ATM further into their network.

For ADSL even on 21cn your modem is still using ATM till it gets to the exchange, so pppoe in that case is pppoeoa = more overhead than pppoa.

For VDSL modems on FTTC there is no ATM, it's PTM which is a bit more efficient for "on the wire" overheads.

FWIW BT do go into some detail, you just need to know where to look =

http://www.sinet.bt.com/sinet/SINs/pdf/472v2p8.pdf

Top of page 13 -

"It should be noted that the use of LLC/SNAP and PPPoE incur a higher protocol overhead and
therefore will provide a lower throughput than the use of PPPoA/VC-mux."

As it says on page 12 that pppoe is llc/snap my previous extra overhead figure is now increased by 8.

Again good information, thanks... I think as my modem and router are separate I am stuck with PPPoE(oA) though!

FWIW I have just set up a Cisco 887VA on my GEA FTTC line with Zen and with no special configuration on my part I am successfully getting 1500 MTU, confirmed by https://www.speedguide.net/analyzer.php

Still not working on ADSL.

I don't trust Zen to not "upgrade" (downgrade) their FTTC stuff too so as soon as my cab is fibre enabled (~ 1 month) I'll be off.

Nice knowing you Zen, but this "upgrade" knackers IPv6 that doesn't play nicely with MSS clamping on most routers. IPv6 "works" but a lot of connections get reset when there is other traffic on the interface.

ISP recommendations welcome. Aquiss & A&A where best bets last time I looked?

On a Zen FTTC connection with a Cisco 887VA handling PPPoE but with a hardware firewall internal to it, Speedguide shows 1500 as the MTU.

On a Zen FTTP connection with just a firewall handling PPPoE I'm currently seeing 1492. I haven't done any tweaking on this yet.

Zen FTTC (80/20) customer here. I've got RFC4638 working correctly with a HG612 3B + EdgeRouter PoE. They definitely haven't dropped support for it, at least on fibre connections.

Excuse my lack of knowledge, but what's the significance of this for a regular Zen Fibre customer, such as myself? (if any)
Thanks.

In reply to a post by AstroflashTB:

Excuse my lack of knowledge, but what's the significance of this for a regular Zen Fibre customer, such as myself? (if any)

This blog post explains it well.

https://kieran.ie/mtu-baby-jumbo-frames-and-fttc/

I think baby jumbo frames are working for me right now on Zen FTTC.
I'm using an Edgerouter X with a HG612 modem.
I have IPv6 enabled on my Zen connection.
I just set the MTU of the PPPoE interface to 1500 and I seem to need to set the MTU of the port the carries the PPPoE to/from the modem to 1516 to be able to send the biggest IPv6 packets, but I haven't quite figured out for sure what is going on. 1508 would definitely be the correct figure for just IPv4 and I'm sure 1516 can't do any harm.

PPP adds 8 bytes so 1508 is the correct MTU for IPV4.
IPV6 would be less than that.

The MTU is the same for both IPv6 and IPv4. One just has a bigger header.

You don't change the IP MTU. That stays at 1500 for both IPv6 and IPv4.

The Ethernet MTU will need to be either 1508, or 1522 depending if the router is including the Ethernet header in its MTU size. Setting it too high shouldn't cause issues.

Edited by Geordish (Mon 08-Nov-21 16:59:28)

Yes, the 1516 MTU figure seems weird to me.

Let me explain how I arrived at it.

I checked my MTU from a Raspberry Pi running the latest Raspberry Pi OS (because Windows does so many things in it's own strange undocumented ways) connected directly to the router.

All ports on the router are explicitly set to MTU 1500 except the PPPoE connection, which was initially set to MTU 1508 (as almost everybody says it should be).

I tested whether pings carrying a certain amount of data could get out by doing pings like this:
ping -Mdo -c4 -s1472 51.148.72.21
or this:
ping -Mdo -c4 -s1452 2a02:8010::100
The figure after the -s is the size of the data in the ping.
The addresses are addresses within the Zen infrastructure that I'm confidant are properly connected with MTU 1500 and which will respond normally to pings. They're actually addresses that appear near the top when I do traceroute to anywhere.

The result of these ping commands is either 4 correct responses from the given address or 4 error messages saying "message too long".

Initially I found the longest IPv4 ping that gave no error was -s1472 and the longest IPv6 was 1444.

Googling seemed to suggest 1472 was correct in most cases for IPv4 and an MTU of 1500.

But it seemed like 1444 for IPv6 was an odd result, so on a hunch I tried increasing the MTU on the PPPoE port one byte at a time and, amazingly, I found the maximum IPv6 ping size increased too.

I was able to increase the maximum IPv6 ping size up to 1452 by setting the PPPoE MTU to 1516 but that was the biggest it would go.

1452 is 20 bytes less than 1472 which does make some kind of sense, though I'm no expert on MTUs, IP and PPPoE.

But I'm rather puzzled by the fact that, as far as I can see, virtually nobody else anywhere on the internet is talking about using an MTU of 1516 to carry dual stack PPPoE.

And why would be overhead due to PPPoE encapsulation change depending on whether the packet inside is IPv4 or IPv6?

Edited by bdg2 (Mon 08-Nov-21 21:49:11)

Those values are the maximum.

The ping utility (in linux anyway..) has the size specified for the payload. An 8 byte ICMP header is attached to that data. So you are sending for IPv4 1472 bytes + 8 bytes ICMP header + 20 bytes IPv4 Header = 1500 bytes..

Similar IPv6 has 1452 bytes + 8 bytes ICMP + 40 bytes IPv6 Header = 1500 bytes.

Setting 1516 bytes on your port seems weird, but its working so I wouldn't look too much further.

In reply to a post by bdg2:

But I'm rather puzzled by the fact that, as far as I can see, virtually nobody else anywhere on the internet is talking about using an MTU of 1516 to carry dual stack PPPoE.

And why would be overhead due to PPPoE encapsulation change depending on whether the packet inside is IPv4 or IPv6?

You are correct to wonder as the 8-byte header is for establishing a layer 2 connection so by definition doesn't have fields for IP addresses (or even care about them).
The baby jumbo ethernet frames only need to exist on the wire if the client (e.g. router or single PC doing PPPoE) and server (e.g. modem bridging PPPoE to PPPoA) are separate boxes, rather than a router with built-in DSL modem.

As others have said the MTU for the actual IP traffic can be 1500 for both IPv4 and IPv6 on standard ethernet and the larger header of IPv6 means it is the MSS (e.g. for TCP) that will be lower.

The reason a router may need to set an MTU of 1508 on a PPPoE interface is more as a means to push the parent ethernet interface's maximum frame size (from L2 default 1518) up by the same amount rather than the router wanting to send IP packets to the modem.

Edited by prlzx (Wed 10-Nov-21 18:42:38)