IPv4 drop bij zware belasting op 4 Gbit verbinding

Hofwel het uiteraard super vervelend is wil ik je even herinneren aan mijn vorige bericht van twee weken geleden waarin ik meld dat u berichtjes gaat krijgen over monteursbezoeken en u dat kunt negeren tenzij er telefonisch contact op wordt genomen. 

Je hebt helemaal gelijk, dat heb je inderdaad gezegd. Ik doe niks meer totdat ik gebeld wordt. Bedankt voor je bericht.

Wat ontzettend vervelend dat er niemand is langsgekomen en je ook niet bent gebeld. Ik snap heel goed dat dit frustrerend is, zeker als je er een halve dag vrij voor hebt genomen. Is er inmiddels al een nieuwe afspraak gemaakt? 

Waarom vraag een kpn moderator dan of er een nieuwe afspraak is gemaakt 

Omdat ​@Beringer een specialist monteur heeft op zijn probleem heeft lopen, en het proces van de specialist wordt (gelukkig) bijna nooit gebruikt en is daarom bij de meeste medewerkers van KPN niet goed bekend. Een nieuwe afspraak is pas aan de orde wanneer beringer wordt gebeld door mijn collega.

De specialist heeft een case neergelegd bij de ontwikkelaar(s) van de KPN Box 14. Wordt vervolgd.

Wat het issue precies zou kunnen zijn is voor mij nog onbekend, bovenstaande is de enige terugkoppeling die ik heb ontvangen.

Fijn dat u contact heeft gehad. Een specialist zal nooit zomaar uw zaak sluiten zonder contact met u, dus weet dat hij zeker nog een keer in de lucht komt. Eventuele toekomstige monteursafspraken welke per mail binnen komen mag u nogmaals negeren tenzij dit telefonisch wordt bevestigd. 

Hopelijk hebben we snel uitsluitsel waarom de box14 dit niet aan kan.

Bump! Nog niks gehoord, maar wil deze wel aktueel houden met jullie.

Euhm... ik heb het topic niet helemaal doorgelezen. Dus misschien kan het al behandeld zijn. Maar heb je dit fenomeen ook 's nachts? Of 3 uur bijvoorbeeld? 

Tijdstip maakt niet uit. Als de lijn vol wordt belast gebeurt het, 3 uur ‘s middags, 3 uur ‘s nachts. Etc. etc..

De titel van dit topic is wellicht wel wat misleidend.

Wat je feitelijk zegt is dat je tijdens het (10 keer) downloaden van een 10GB bestand timeouts krijgt op IPv4 pings terwijl de pings op IPv6 door blijven lopen.

Ik denk dat het feit dat er sprake is van dual stack IPv4 / IPv6 ook weleens zou kunnen betekenen dat er verschillende “communication queues” zouden kunnen zijn voor IPv4 en IPv6.

Als de IPv4 queue dan volledig gevuld is door die download terwijl er via die IPv6 queue naast die ping nauwelijks communicatie is, dan zou dat dit fenomeen heel goed kunnen verklaren en dan is er eigenlijk ook helemaal niets mis.

Kan jij vaststellen of er voor de download (wget commando) wellicht IPv4 gebruikt wordt?

Komt IPv4 weer op zodra de download afgerond is?

Overigens lopen zowel IPv4 als IPv6 via de pppoe verbinding. Er wordt inderdaad een IPv6 prefix via DHCPv6-PD verkregen maar dat loopt binnen de pppoe verbinding.

“Wat je feitelijk zegt is dat je tijdens het (10 keer) downloaden van een 10GB bestand timeouts krijgt op IPv4 pings terwijl de pings op IPv6 door blijven lopen.”

Nee dat zeg ik niet. Ik zeg dat de gehele IPv4 laag eruit klapt bij zware belasting van de lijn. Dus niet enkel ICMP replies maar de complete IPv4 laag. Naast ICMP replies is er helemaal geen IPv4 internetverkeer meer mogelijk, zowel inkomend als uitgaand, maar wel op IPv6.

En dit gebeurd bij zowel speedtests als reguliere downloads, ongeacht het tijdstip. Ik kan het echter wel heel simpel en snel reproduceren middels een aantal speedtests, wat enkel makkelijk is voor eventuele KPN engineers die live mee willen kijken naar de lijn.

En de IPv4 komt na 5 of 6 mins weer terug als deze eruit is geklapt. Dus de download hoeft nog geeneens gereed te zijn, het duurt gewoon zolang als de verbinding eruit klapt om weer terug te komen met IPv4.

Ik heb dit enkel op de 10Gb poort. Op de 2,5Gb en 1Gb poortjes niet maar daarmee kan ik uiteraard ook niet het max haalbare halen van de lijn.

Ik denk toch dat dit puur een queueing issue is. Het vollopen van de IPv4 queue waardoor IPv4 verkeer in de queue achteraan moet aansluiten en daardoor sneller tegen een time-out zou kunnen aanlopen.

Duurt het ook 5 á 6 minuten als de download al na 1 minuutje afgerond is?

Wat bedoel je met als de download na 1 minuut afgerond is?

En als het een queueing issue is, dan zou dat toch enkel betekenen dat de Box 14 niet overweg kan met 4Gb/s?

Als jij 10GB download met een snelheid van 4Gbps dan zou de download na ongeveer 20 seconden afgerond moeten zijn. Duurt het in zo'n situatie dan ook 6 minuten voordat IPv4 weer actief wordt?

Nee, een wachtrij (queue) ontstaat sowieso als de maximaal haalbare bandbreedte ook daadwerkelijk gebruikt wordt en dan is het inherent dat communicatie traag wordt en zelfs heel traag als die communicatie maar een heel klein deeltje van de totale communicatie betreft. Het is dus volstrekt logisch dat de ping berichten als eerste een time-out gaan krijgen aangezien 99,999% van de communicatie dan aan andere zaken besteed wordt.

Nee 10GB is net te weinig om eruit te klappen. Ik moet er 2 of 3 direct achter elkaar zetten om het te reproduceren. En dan gebeurt het niet na de download maar tijdens, en vanaf dat moment duurt het dan weer 5 of 6  mins om terug online te komen.

Nogmaals, het gaat niet om ping maar om alle protocollen op IPv4 die dan niet meer functioneren. Dus mail, http, ftp, vpn, etc. etc. Alles wat middels IPv4 werkt doet het dan niet meer.

Aanvullend, de Assurance Plus Monteur van KPN die bezig is met deze case heeft het issue erkend nadat hij op afstand mijn lijn doormeette en ik het issue op dat moment reproduceerde, en heeft het daarna intern uitgezet.
Dus ik denk dat het niet zo iets simpel is als een queueing issue want dan zou deze beste man dat toch wel benoemd hebben lijkt mij?

Ik zeg ook niet dat het alleen om ping zou gaan, ik zeg alleen dat ping berichten als één van de eerste tegen een time-out aan zullen lopen omdat ze maar een minuscuul deeltje van de totale communicatie zijn.

ICMP heeft ook lage prio, dus ja, ping replies gaan er als eerste aan maar dat staat los van dit issue.​ Er gaat iets niet lekker op de Box 14 of in laag 3 maar dat zal KPN uit moeten gaan wijzen.

Totaal niet belangrijk maar die assurance plus monteur heeft hem doorgezet naar een specialist. AS+ monteurs bewaken zelf geen orders en kunnen ook niet bijzonder veel extra als "normale"  monteurs.

​@Beringer Het is al een tijdje stil in dit topic, dus ik ben benieuwd hoe het nu gaat. Is er inmiddels telefonisch contact met je opgenomen?

Nee, ik ben nog niet gebeld. De laatste berichtgeving vanuit de Assurance Plus Monteur is dat er melding is gemaakt bij de ontwikkelaar van het modem, dit was op 9 januari. Daarna niets meer gehoord.

Oke, dan is het nog even afwachten. Ik ga er vanuit dat mijn collega's dit nog aan het uitzoeken zijn.

Heb gisteren als test een pfSense machine geplaatst met een dual Intel 10GB NIC. De hele KPN Box 14 dus afgekpoppeld, en de pfSense doos de PPPoE sessie laten opbouwen.

Nog steeds dezelfde problemen, bij zware belasting van de lijn valt de IPv4 laag valt weg en IPv6 blijft werken. Na 5 à 6 minuten komt IPv4 weer terug online.

Hiermee kan ik wel concluderen dat het issue zich niet in de KPN Box 14 bevindt aangezien het probleem exact hetzelfde is met een pfSense oplossing. Dan zit het wellicht toch in de Nokia ONT of verder in het netwerk of misschien in de centrale hier verderop in de straat.

Ik zal deze resultaten ook delen met de Assurance Plus Monteur die mijn case in behandeling heeft.

Bump!