PPPoE MTU issue

RouterOS General
1

Hello.

I have a very very simple network just to check some things.. as simple as PPPoE server (RB 750) ↔ PPPoE Client (RB 750)

The pppoe server is:

service-name="pppoe-server"
interface=ether2-pppoe-server
max-mtu=1500
max-mru=1500
mrru=disabled
authentication=pap,chap,mschap1,mschap2
keepalive-timeout=10
one-session-per-host=no max-sessions=0
default-profile=default

But, client pppoe drops to 1480 MTU size.

I saw a post in this forum with similar issue but it’s from 2016 without solution.

If in the pppoe-client I’ll fix a 1500 Max MTU, it starts with a 1492 and drops to 1480 in a few seconds.

I’ve tried to increase ethernet MTU, and no change at all.

Any clue?

2

1480 should be used on both PPPoE server and client

Typically, the largest Ethernet frame that can be transmitted without fragmentation is 1500 bytes. PPPoE adds another 6 bytes of overhead and PPP field adds two more bytes, leaving 1492 bytes for IP datagram. Therefore max PPPoE MRU and MTU values must not be larger than 1492

Default MRU and MTU is 1480 on Mikrotik PPPoE server:

The optimal value is the MTU of the interface the tunnel is working over reduced by 20 (so, for 1500-byte Ethernet link, set the MTU to 1480 to avoid fragmentation of packets)

Ref:
https://wiki.mikrotik.com/wiki/Manual:Interface/PPPoE#PPPoE_Server_Setup_.28Access_Concentrator.29

3

Your PPPoE MTU is 1500
Then you maximum ICMP payload is 1472(1500-20(IP header)-8(ICMP Header).
By default PPPoE 1480 bytes and maximum ICMP payload is 1452 bytes.

4

Thanks Solar77.
I agree that as the max MTU is 1500 and with the PPPoE (6 bytes) and the PPP (2 bytes) the max MTU for the PPPoE must be 1492 (1500-6-2). Thats what I want to achieve.

At first, I dont understand the 1480 hard-fixing for the PPPoE mikrotik tunnel.
Furthermore, many home routers, like cheap TP-LINK, shows 1492 for PPPoE MTU. Mikrotik claim 1500 reduced by 20… why 20? Where this value come from? Seems to me that this is an arbitrary value. For sure it is not! But I like to know the reason for this value and the way to use the “standard” 1492.

Maybe I’m completly wrong and 1492 value on TP-LINK PPPoE client router and the 1480 for the Mikrotik environment are not the same…

Thaks Anumrak.
But I’m afraid I’m no talking about fragmentation issue. It’s just the PPPoE negotiation.

Regards!

5

To be honest I am not sure. Look forward to hear from other exports about the technicality of it.

However in practice. the Mikrotik default 1480 is what I always use and never let me down. If I have to change anything it would be the client CPE and I test with ping -f -l xxxx, where the xxxx is the size of packet to sent. Run this from Windows PC tells you if this size can be transmitted without fragmentation and therefore you can tell the Max value is.
Hope this information helps you.

6

1480 bytes in PPPoE tunnel came from extra overheads in frames, if want to use pppoe over vpls or over eoip or all these over l2tp/ipsec :slight_smile:

7

so I take it 1492 is good for general PPPoE on it’s own? why would fragmentation cause issue for some CPE to drop PPPoE session?

8

So, maybe it’s not fragmentation? Maybe it’s enabled compression it pppoe profile? It is drop PPPoE connection with tense traffic.

9

I had one CPE that was set to 1492, it connects to our Mikrotik via PPPoE and the profile is 1480.
the link was not stable and whenit was connected, it can ping google.com , can search google but clicking on any searching result, the page will timeout. ping a web url, works fine, get the IP. put it in browser address bar of same PC, timeout. change the URL to IP address, it works.
Not knowing he had set MTU to a different value (I don’t know exactly what) ,it took me ages to diagnose this issue. Once MTU changed to 1480, to match our PPPoE server profile. It worked fine.
but still don’t understand why the network behaved as such.

10

Well, I believe there is some transit node, maybe switch, that drops all frames with mtu higher than 1506 bytes. In bad case, you have 1518(1492+8(pppoe)+18(ethernet + vlan). With 1492 MTU in PPPoE interface (for web surfing, f.e.) PC generating TCP MSS segments with web site with 1452 bytes. Means 1452+20(tcp)+20(ip)+8(pppoe)+14(ethernet)+4(vlan)=1518 byte frames. Switch might drop it or buged ROS in Tik in PPPoE server. With PPPoE MTU 1480, we have TCP MSS 1440 and 1506 bytes full vlan frame. So, you should look in Tik log about session termination with asynchronization cause of compression enabled, update your ROS and check MTU in switches, if you have.

11

Thanks Anumrak. the issue was resolved by setting 1480 at client router. will read up more on this topic.

12

I was always wondering why the default value is 1480. Isn’t best practise 1492?

How would there be fragments when the PPPoE Client packs everything into a 1492 large paket?

13

Yeah, I agree with Anumrak. If the TCP MSS negotiated between computer and web server is big enough to require a full ethernet frame, could behave like that because ot the mismatch in the PPPoE tunnel negotiation. But that’s beyong my knowlenge.

Anyway, the problem saw by solar77 is exactly the same that I would see if the routers we install on clients house didn’t perform MTU negotiation. And I will like to know why I must trust to Mikrotik’s criteria and keep 1480 and how to increase it to 1492 if I prefer to.

Sometimes, a client ask us if he can create the PPPoE tunnel with their handsome router… and who knows how MTU is configured there!

14

Yeah! Exactly my point!


Exactly. Where the additional 12 bytes (1492 - 1480) come from?

Please MK guys, enlight us! :slight_smile:

15

Headers remain untouched. Your payload go through with it’s MSS, router send icmp back that i fragmented your frame, give me part 2, then your PC send 12 more bytes as second fragment of payload data.