Hoe de juiste MTU instellen

wortel · 7 april 2026 om 17:30

Vandaag overgegaan van Odido naar Freedom. Mede dankzij Aanschafadvies i.v.m. andere belichting (AON) na overstap van Odido - 4 van Larry was ik goed voorbereid.
Mijn TP-Link MC220L had ik nog op “force” staan wat niet werkt. Schakelaartje op “auto” gezet en toen had ik verbinding.

De enige kanttekening is dat de speedtest enigszins tegenvalt. Ik heb het vermoeden dat dit met de MTU waarde van 1494 van mijn PPPoE interface te maken heeft. Volgens Freedom dient deze op 1500 te staan en als ik het goed interpreteer kan de rest op de standaard waarde blijven.

Is MTU 1500 noodzakelijk op de PPPoE interface ? Zo ja, kunnen de bijbehorende ethernet interface en VLAN op de standaard waarde 1500 blijven ?
In menig voorbeeld worden deze twee namelijk hoger gezet. Bijvoorbeeld:

github.com/rweijnen/unifi-cloudgateway-ultra

change-ppo-mtu-kpn.md

main

The UCG Ultra keeps it config in a file name `ubios-udapi-server.state` which is stored in `udapi-config/ubios-udapi-server`.
It's a json file that looks a lot like the json file from the USG, however it's not meant for direct modification.

[Reference](https://community.ui.com/questions/Research---Understanding-ubios-udapi-server-state-and-how-to-make-changes-persist-on-UniFi-consoles/0bc217af-2e26-48b3-ba71-29630a06ffdb?page=1)

It's modified like this:
1) copy the file, in this example to the home folder:
`cp /data/udapi-config/ubios-udapi-server/ubios-udapi-server.state ~`

2) create a copy of the file and name it udapi-request.json, this is the copy we are changing, the other one will serve as a backup
`cp ~/ubios-udapi-server.state ~/udapi-request.json`

3) we need to modify the mtu values for ETH4, ETH4.6 and PPP0 interfaces, here are the relevant sections from the json:
```json
identification": {
    "id": "eth4",
    "type": "ethernet"
   },
   "status": {
    "arpProxy": false,

Dit bestand is afgekapt. origineel weergeven

Mijn router is een UniFi Cloud Gateway Ultra waarop MSS Clamping op “Auto” staat.

Larry · 7 april 2026 om 19:03

Thx. tldr; dingen zijn niet noodzakelijk en wordt vooral bepaald door de totale situatie. Het gaat bij MTU vooral om fragmentatie=overhead, te voorkomen.

MTU verhaal wat (niet) beter is.

Beperken van fragmentatie zodat de communicatie (laag) cq andere apparatuur gemiddeld gezien - end2end - minder overhead bezigt. Bezie de MTU size, dus ook op de plaats waar die sèc van toepassing is.

Technisch op/in ethernet transport cq. plat “lan/wif” is het optimale van oudsher 1500 bytes is.
Afhankelijk van situatie, komt er voor WAN verkeer daar nog 8 bytes bij voor de PPPoE encapsulatie en (eventueel) 2 bytes om een VLAN te duiden.
Het actuele PPPoE pakketje, dat dus dan de ‘router’ uit gaat, wordt daarmee dan 1512bytes met daarin dus die gewenste 1500 (dat “optimaal”) van/voor switched Ethernet.
Wanneer echter de “transportlaag” tussen jou en Freedom; minder dan die 1512 bytes kan switchen, moet elk pakketje van 1512 of bij fouten worden verdeeld in meerdere (her)transmissies.
Dan is het efficiënter om in je eigen thuisnetwerk, bv maar 1488 te gebruiken.

In een ideale DSL omgeving, blablah, is de optimale MTU grootte doorgaans 1492 (+8 byte ppoe) en wanneer je gaat (uit)bellen en encryptie gaat toepassen, kan dat afnemen naar 1460 (vpn), 1452 of zelfs nog minder naar soms maar 512 (bv radio/satelliet), oldskool of Lora modems nog (flink) minder.

Kortom, wat optimaal is, wordt bepaald door de totale ketting van de ingezette transportmethodes. Beperking is dat als gebruiker niet vooraf kunt weten noch dingen kunt bepalen.

In een stabiel (local & ruim behuisd) LAN zelf, mits mogelijk, kan je ook grotere Jumboframes toepassen.
Een transportframe wordt dan bv 9000 bytes wat flink aan (switch) overhead spaart. Er hoeven dan, in ruil voor zwaardere=duurdere apparatuur, minder pakketjes te worden geschakeld.
Wat wijsheid/onzinnig is, wordt dus ook hier bepaald door een situatie.

Met commando ping -f -l 8000 ip.ad.dr.es ^{(linux: ping -M do -s 8000 ip.ad.re.ss} kan je uitvinden of/wanneer fragmentatie plaatsvindt.
Bij “te groot” krijg je een fout en maak je de afmeting kleiner totdat het goed gaat. In mijn netwerk maak ik o..a gebruik van channels e.d. en mijn optimale MTU thuis is 1472. Voor extern naar Freedom wordt dat 1464.

Voor ons, consumenten, het beste om de standaard “apparatuur” op interface niveau dingen zelf te laten uit onderhandelen. Hierbij ga ik er vanuit dat de gebruiker & leverancier niet zelf slimmer proberen te zijn door dingen te forceren.

jschwart · 8 april 2026 om 16:58

Noodzakelijk is het niet, maar zou in theorie iets optimaler zijn. De bijbehorende ethernet interface moet een MTU van 1508 hebben om PPPoE op 1500 te laten passen. (De PPP header voegt 8 bytes toe.)

Een waarde van 1494 lijkt bijzonder, ik verwacht dat dat nu 1492 is.

Ik begrijp dat wortel juist geen standaard apparatuur gebruikt. Dan zal je zelf de optimale waarden in moeten stellen voor hetzelfde resultaat. In de spullen die Freedom uitlevert, zit een specifiek profiel gericht op Freedom wat dit regelt.

wortel · 9 april 2026 om 08:12

Het is inderdaad 1492. Excuses voor de typo.

Op de Freedom pagina voor gebruik met eigen modem staat o.a. het volgende:

ETH (interface): 1508 (1510 voor Glasvezel Helmond) (opleveringen tot okt 2024, anders standaard)

Denk dat daar de verwarring zit bij mij.

Bedoelen ze dat alleen aansluitingen tot okt 2024 een MTU van 1508 op ETH moeten gebruiken ?
De standaard is op mijn router is MTU 1500 is op de ETH interface.

Ref.: Welke instellingen heb ik nodig voor mijn eigen modem? | Freedom Helpdesk

bastiaan · 9 april 2026 om 08:24

Ik weet niet waar je het over hebt. Ik zie het niet meer staan hoor…

Aangezien we geen verbindingen meer op de speciale Glasvezel Helmond instellingen hebben, heb ik die informatie even van de pagina af gehaald. Dat moet het duidelijker maken.

wortel · 9 april 2026 om 09:01

Bedankt voor het ophelderen