Ik ben momenteel bezig met de overgang van mijn verbinding van Tweak.nl naar Freedom. Vandaag is mijn Tweak verbinding om 7:01 uur verbroken en zou mijn Freedom-verbinding moeten starten (bevestigd gekregen per mail op 25-07 en besproken met @bastiaan ), maar helaas heb ik momenteel geen werkende verbinding. Ik vermoed dat dit te maken kan hebben met mijn configuratie van de UDM SE, ervanuit gaande dat de verbinding nu al actief zou moeten zijn bij Freedom (of moet ik nog wachten?). Ik zou graag wat advies en hulp willen krijgen om mijn configuratie in orde te maken.
Tot nu toe heb ik dezelfde opstelling gebruikt die ik bij Tweak had, waarbij ik bij inschrijven opnieuw heb gekozen voor het Cambrium-netwerk (zie eerdere post: Vraag mbt overlap tijdens transitie). Mijn setup is als volgt: het glasvezelsignaal komt binnen via de Media Converter en van daaruit gaat een UTP-kabel naar WAN 1 (Poort 9) op mijn UDM SE. Deze opstelling werkte prima bij Tweak.
Ik heb geprobeerd de instellingen van de Freedom-handleiding “Instellingen voor de glasvezelverbinding” te volgen, maar ik loop tegen enkele obstakels aan. Hier zijn de stappen die ik tot nu toe heb genomen:
Ik heb de VLAN ID gewijzigd van 34 naar 6.
Onder “IPv4 connection” heb ik de schakelaar omgezet van DHCPv4 naar PPPoE.
Ik heb de gebruikersnaam (fake@freedom.nl) en het wachtwoord (1234) ingevoerd, zoals in de handleiding aangegeven.
Ik heb het IPv4 CIDR ingevoerd dat ik van Freedom heb ontvangen.
Een van de struikelblokken voor mij zijn de MTU-waarden. Volgens de handleiding moeten de waarden worden ingesteld op: ETH interface 1508, VLAN 6: 1508 en PPPoE 1500. Hier kom ik echter in de problemen. Aangezien ik een UDM heb, moet ik gebruikmaken van de MSS Clamping-functie. Deze functie biedt drie opties: Auto, Disabled en Custom.
Ik heb geprobeerd de Custom-optie te gebruiken, maar kan ik alleen 1 waarde opgeven (dus niet verschillende per interface). De waarde is: “Max TCP connection segment size”, maar ik kan de waarde niet instellen op 1500; het systeem geeft aan dat 1452 de maximale waarde is. De handleiding suggereert dat als 1500 niet mogelijk is, de volgende formule moet worden gebruikt: 1500 - 4 - 8 - 40 = 1448 (MTU - 802.1q - PPPoE - IPv4).
Ondanks dat ik de MSS Clamping op 1448 heb ingesteld, krijg ik nog steeds geen verbinding. Ik heb zowel de Media Converter als de UDM SE opnieuw opgestart nadat ik alle instellingen heb toegepast, maar mijn verbinding blijft offline.
Zijn er andere stappen of instellingen die ik over het hoofd heb gezien? Alle hulp en suggesties zijn welkom. Alvast bedankt voor jullie tijd en moeite!
Link naar de Freedom handleiding die ik heb gevolgd:
Ik zou zelf, eerst, proberen dingen met een el-cheapo cq standaard modem proberen.
Daar je aansluiting via de mediaconverter vinnenkomt, kun je ook proberen lokaal een PPoE via een PC/Laptop op te bouwen. Puur allemaal om te zien om het glas werkt.
Die MTU en daarmee MSS waarden, zou ik lager inzetten of laten defaulten - wordt dan immers verder onderhandeld - om mee te beginnen.
Ik heb de oude modem/router nog van Tweak. Die mag ik houden zeggen zij. Ik kan em proberen fabrieksinstellingen te resetten en configen. Gaat om een ZyXel. Ik heb namelijk geen andere modem liggen at the moment.
Het is wel firmware provided by tweak, is het anders een beter idee om te kijken of er default firmware te downloaden is en die dan uploaden om pre-configs te voorkomen? Weet jij of dit een issue is?
MSS Clamping is een afgeleide van de MTU. Het is een goede instelling voor MSS, niet voor MTU.
(MSS = de Netto inhoud van een pakket voor IP protocol, MTU is de bruto maat van een pakket voor het transport medium).
MTU is de maximale packetsize die je mag verwachten voor ethernet is dat regulier 1500.
PPPoE snoept daar 8 bytes vanaf voor het PPP protocol.
Sommige hardware en sommige ISP’s laten MINI-JUMBO frames toe (netwerk pakketten die een fractie groter zijn),
Bij Freedom kun je MTU = 1508 gebruiken zodat je 1500 byte ethernet frames door het internet kan duwen ondanks de PPP overhead.
Dit voorkomt dat grote pakketten gefragmenteerd worden (als 1500 byte pakketten verzonden worden dat er dan een deel van 8 bytes en een deel van 1492 bytes verzonden wordt).
MSS doet net zoiets maar zorgt dat ervoor dat IP pakketten zodanig krimpen dat fragmentatie niet optreed.
Zelf doe ik een basischeck door mijn PC direct op de media converter aan te sluiten en die als PPPoE client configureren. Weet je niet hoe of wat, dan kunnen dingen wat lastiger zijn en raad ik aan je te laten (bege)leiden door de helpdesk (dat best FF kan duren) dat begint met check of een aansluiting wel is opgeleverd.
Ik wil even een update delen over de voortgang van mijn internetverbinding. Gisteren had ik contact met freedom helpdesk om te verifiëren of mijn lijn daadwerkelijk was opgeleverd. Anders was troubleshooten beetje nutteloos.
Na wat onderzoek kwam Sebas (freedom: ik vermoed @sebas ? Sorry als het verkeerde tag is) tot de conclusie dat er een configuratiefout was gemaakt door Cambrium, en zij dat pas aanstaande maandag kunnen verhelpen.
Het is belangrijk om op te merken dat deze fout niet te wijten is aan Freedom, maar eerder aan een fout in de configuratie van/door Cambrium.
Wat ik vooral wil opmerken, is de buitengewone klantvriendelijkheid van Sebas. Ondanks dat het probleem niet door ons was veroorzaakt, heeft Sebas ervoor gezorgd dat ik een tijdelijke hotspot krijg waarmee ik mijn UDM SE kan verbinden. Hierdoor kan ik tenminste tot maandag (of zelfs langer, afhankelijk van Cambriums hersteltijd) internet blijven gebruiken.
Ik wil Sebas en de helpdesk hartelijk bedanken voor hun inspanningen om een tijdelijke oplossing te bieden, ook al lag de oorzaak van het probleem buiten hun invloedssfeer. Ik kijk nu vol verwachting uit naar maandag en zal jullie op de hoogte houden zodra ik een update heb over de situatie.
Mooi te lezen dat Freedom, ook “in” is voor hulpvaardige connectie alternatieven en Sebas is idd een prima voorbeeld hoe het team olied.
Of en wat de fout bij Cambrium zou kunnen zijn geweest, vat ik samen dat de lijn kennelijk vermoedelijk nog niet was opgeleverd.
Even voor lerende beeldvorming. Naar ik begrijp heb je een NTU, gaat daar in de huidige foutsituatie ĂĽberhaupt wat (vaker dan 1-2x) knipperen wanneer je de ethernet van je router er in doet ? Zo ja er activiteit is, zal er idd een logische (config) fout zijn.
Zo nee, zal het glas niet actief zijn (zo je aandurft & kunt, kun je ook het licht bestuderen met een camera/witpapier).
Ik heb het advies van @GraveR meegenomen en het IP-adres verwijderd. Gisteren middag heeft Cambrium de aanpassing uitgevoerd waardoor mijn internetverbinding direct actief was.
Hiermee is de conclusie dat de configuratie klopt, of in ieder geval werkend is. 1448 heb ik nog steeds staan als Max TCP connection segment size. Is het nog wel een idee om die op Auto te zetten? @anon0224
Mooi dat het werkt en kennelijk was het een opleverprobleem.
Wat ik bedoelde dat wanneer 1500 (laat staan mini/jumbo frames van > 1500) of in jouw geval 1448 niet werkt, die lager of op default/auto instellen.
De (opwaartse) optimalisatie vanuit MTU e.d. is doorgaans fijntuning en zelf zet ik dat in beginsel - zo ja - bv op 1376 zodat ook eventuele andere ingepakte (bv IPSEC) protocollen kunnen functioneren.
Is het een Linux machine…
Dan moet MTU ook instelbaar zijn… De vraag is waar dat het beste kan.
Ik heb geen UDM, dus ik je daar niet bij helpen, maar eerst uitzoeken hoe de netwerk config gedaan wordt helpt…
– systemd-networkd
– Network Manager
– Klassiek config (distro afhankelijk)…
Aanvulling: Het is in het artikel beschreven …
Je hebt geen JUMBO frames van 9K nodig. Alleen aanpassing van WAN naar 1508.
MTU != MSS
MTU van 1500 zou ingesteld moeten kunnen worden…,
Kaal ethernet:
Ethernet packetsize = 1500
MSS = Ethernet MTU - (IP header size = 20(IPv4)) - (TCP header size = 20 (IPv4)). = 1460 by regulier ethernet.
MSS bij IPv6 is een stuk lastiger omdat er variabele headers kunnen zijn.
MTU = 1500 is de normale
PPPoE over kaal ethernet:
PPP interface MTU = Ethernet MTU - (PPP Headersize = 8) = 1492.
MSS = MTU - (PPP header size = 8) - (IP Headersize = 20) - (TCP headersize = 20) = 1452.
PPPoE over mini Jumbo ethernet:
Ethernet packet size = 1508.
PPP interface MTU = Ethernet MTU - (PPP Headersize = 8) = 1500.
MSS = MTU - (PPP header size = 8) - (IP Headersize = 20) - (TCP headersize = 20) = 1460.
(Voordeel, de router zal geen hak/plak hoeven te doen om pakketten door te sturen. Het onvangende systeem aan het eind hoeft minder data te bufferen en mider data 1 of meerdere malen te kopieren als het volgende segment binnenkomt).
Bij tunneling van protocollen zoals bij IPSEC / GRE / OpenVPN / Wireguard etc. gaan ook die headers nog van de packet size af.
Dan kan het handig zijn om alle systemen waar het verkeer over die tunnel gaat van een kleinere MTU te voorzien, “alles” om fragmentatie te voorkomen.
Je kan soms auto detect instellen voor packet omvang, dan wordt optimistisch een normaal packet gestuurd met als attrubuut DON’t fragment, de router die het dan niet door kan sturen stuurt een ICMP terug dat het niet lukt vanwege te grote pakketten, dan zal de eerste zender een kleinere maat kiezen tot het wel werkt.
Als je een 1500 byte MSS wil gebruiken heb je voor Ethernet frames nodig van 1500 + 40 en bij PPPoE frames van 1500 + 40 +8 nodig hebben. (Dat gaat in de meeste gevallen niet werken)
In de UI kun je het niet toepassen, je zou er voor kunnen kiezen de MTU van de interface en de tunnel iedere 5 minuten op 1508/1500 te zetten maar of je er echt iets mee opschiet…
