20% packet loss op KPN nlsix switch

Is dat het eindpunt van jouw MTR?

Je kunt helemaal niets zeggen over de tussenpunten. Die mogen ICMP pakketjes gewoon droppen en vaak zit daar ook een rate-limiting aan vast. Het gaat dus om de latency en dropped pakketjes op jouw eindpunt. Is dat ook 20% of meer??

Lees punt #2 op deze pagina ook even: MTR #2: Packet loss - or is there?

Ik wil niet zeggen dat er geen probleem is met de peering van dat doel, maar op packetloss op een tussenpunt van een MTR kun je dus niets beoordelen.

Bij mij geeft ie zelfs tot 80% packetloss op dat tussenpunt (wat dus heel normaal is).

 Host                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. mijnmodem.kpn                      0.0%    91    0.7   1.1   0.6   9.7   1.3
 2. 2001:67c:2502:f100::2:b            0.0%    91    3.0   4.8   2.7  19.7   3.0
 3. kpn-as1136.kpn-asd-dc2.nlsix.net  79.8%    90    5.2   5.7   5.1   9.5   1.0
 4. (waiting for reply)
 5. vlan102.r06.spine101.ams02.fab.ne  0.0%    90    5.4   5.6   4.9  16.6   1.6
 6. vlan106.r02.leaf106.ams02.fab.net  0.0%    90   18.7   6.4   5.1  18.7   2.4
 7. vlan102.r08.tor106.ams02.fab.neta  0.0%    90    5.0   5.4   5.0  10.7   0.9
 8. g2a02-26f0-1180-0071-0000-0000-0210-6a19.deploy.static.akamaitechnologies.com
                                       0.0%    90    4.9   5.5   4.8  16.9   1.6

Bedankt voor de link! Die bevestigt precies wat ik zie. Punt #2 van Cloudflare (MTR #2) verklaart inderdaad waarom mijn IPv4 MTR er 'vies' uitziet maar wel snel werkt (0% loss op het eindpunt).

Echter, als je naar mijn IPv6 MTR kijkt en dit vergelijkt met Cloudflare's MTR #3, zie je dat de loss op de KPN-peering wél zorgt voor problemen op het eindpunt. In de browser resulteert dit in TCP-retransmissions van meerdere seconden.

Het feit dat IPv4 (met 90% 'nep' loss) direct laadt, en IPv6 (met 20%-60% 'peering' loss) seconden blijft hangen, bewijst volgens de logica van Cloudflare dat de IPv6-route van KPN simpelweg defect is.

Ik zie jouw IPv6 MTR nergens?? Overigens had ik ook IPv6 gedaan en heb dus ook 80% verlies op datzelfde punt.

Maar nee, je kunt dus geen conclusie trekken dat bij packetloss op een tussenpunt er iets met de peering is. ICMP antwoord (of gebrek daaraan), wat dus MTR aangeeft, heeft niets te maken met die problemen.

Ik geloof best dat je problemen hebt, maar die kun je niet diagnosticeren met MTR.

*) Ik neem aan dat je met IPv6 dezelfde route ziet die ik hierboven aangaf? (Ik heb met images.nu.nl geen problemen)

*) Wat is precies het probleem en hoe ervaar je dat?

*) Heb je “Veilig Browsen” in de Mijn KPN al eens uitgezet (er wil nog wel eens een verkeerde URL op die bloklijst terecht komen)?

*) Kun je in de browser ‘onderwater’ kijken met F12 en kijken wat voor foutmeldingen je ziet op images.nu.nl?

*) Worden alle images van images.nu.nl geblokt of zie je daar alleen ‘traagheid’ ?

Hi,

IPv6 heb ik gedeeld als 1e post. Fedora gebruikt v6 default als het beschikbaar is.

Packetloss als in 100% is prima. 20-60% niet.

*) Ik neem aan dat je met IPv6 dezelfde route ziet die ik hierboven aangaf? (Ik heb met images.nu.nl geen problemen)

> De v4 route laat alleen 0% of 100% packetloss zien. De v6 op de KPN node 20-60%

*) Wat is precies het probleem en hoe ervaar je dat?

Grote afbeeldingen laden soms langzaam, door de retries die de browser moet doen

*) Heb je “Veilig Browsen” in de Mijn KPN al eens uitgezet (er wil nog wel eens een verkeerde URL op die bloklijst terecht komen)?

Staat niet aan

*) Kun je in de browser ‘onderwater’ kijken met F12 en kijken wat voor foutmeldingen je ziet op images.nu.nl?

Ik zie geen afbeelding gerelateerde foutmeldingen (alleen Adguard Home blocks op tracking)

*) Worden alle images van images.nu.nl geblokt of zie je daar alleen ‘traagheid’ ?

Meestal prima, maar soms zie je ze opbouwen.

Als ik Fedora dwing om v4 te gebruiken is het goed.

​@mdra Zoals rvk01 al zei, de noden hoeven niet op ICMP te reageren. Pakket lost betekent bijna altijd dat deze gewoon droppen ipv een antwoord te geven. Nu de ipv6 en ipv4, ipv6 99% lost bij nlsix, bij ipv4 100% lost

|                       Host              -   %%  | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------|------|------|------|------|------|------|
|
| xxxxxxxxxxxxxxxxxxxxxxxxx.fixed6.kpn.net -    0 |  238 |  238 |    1 |    1 |    4 |    2 |
| 2001:67c:2502:f100::2:40                 -    0 |  238 |  238 |    3 |    4 |   10 |    3 |
| No response from host                    -  100 |  546 |    0 |    0 |    0 |    0 |    0 |
| kpn-as1136.kpn-rt-dc2.nlsix.net          -   99 |  102 |    2 |    0 |    4 |    4 |    4 |
| No response from host                    -  100 |  533 |    0 |    0 |    0 |    0 |    0 |
| vlan102.r32.spine101.ams02.fab.netarch.akamai.com -    0 |  238 |  238 |    4 |    5 |    8 |    5 |
| vlan132.r04.leaf106.ams02.fab.netarch.akamai.com -    0 |  238 |  238 |    4 |    5 |   26 |    6 |
| vlan104.r08.tor106.ams02.fab.netarch.akamai.com -    0 |  238 |  238 |    4 |    5 |    7 |    5 |
| g2a02-26f0-1180-0071-0000-0000-0210-6a16.deploy.static.akamaitechnologies.com -    0 |  238 |  238 |    4 |    4 |    8 |    5 |

|                       Host              -   %%  | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------------|------|------|------|------|------|------| xxx-xxx-xxx-xx.fixed.kpn.net             -    0 |  142 |  142 |    2 |    3 |   10 |    4 | No response from host                    -  100 |  183 |    0 |    0 |    0 |    0 |    0 | No response from host                    -  100 |  183 |    0 |    0 |    0 |    0 |    0 | No response from host                    -  100 |  183 |    0 |    0 |    0 |    0 |    0 | nl-ams14a-ri1-ae-8-0.aorta.net           -    0 |  142 |  142 |    5 |    7 |   49 |    6 | 185.100.113.131                          -    0 |  142 |  142 |    5 |    6 |    9 |    6 | No response from host                    -  100 |  183 |    0 |    0 |    0 |    0 |    0 | No response from host                    -  100 |  183 |    0 |    0 |    0 |    0 |    0 | No response from host                    -  100 |  183 |    0 |    0 |    0 |    0 |    0 | a96-16-53-156.deploy.static.akamaitechnologies.com -    0 |  142 |  142 |    6 |    6 |    8 |    7 |

Ook dit is niet waar. Tussen nodes hebben heel vaak rate limits op ICMP pakketjes zitten. Dit doen ze zodat je ze dan wel in een traceroute kunt zien (en ze daar dus zichtbaar zijn i.p.v. * * *) maar als je er 2 of meer binnen een paar seconden doet dan kunnen ze die gewoon droppen. Plus dat ICMP een lagere prioriteit heeft op die tussen nodes. Dit is echt niet het probleem. Verkeer van en voor het eindpunt wordt niet gedropt. Wel kun je e.v. kijken of je spikes in de latency hebt op images.nu.nl.

Je zegt dat de browser retries probeert te doen. Daar was ik n.l. benieuwd naar. Want dat zou je dan toch onder f12 moeten kunnen zien? 

(Jouw mtr in je openingspost was niet compleet. Dat was alleen maar 1 regel.)