121 replies to this topic

[gjstroom]

Het lijkt wel of je steeds via een andere weg bij downloads.openpli.org terrecht komt:

Een paar maal achter elkaar mtr op een Ubuntu machine via Ziggo:

gertjan@ds9:~$ mtr -Twn -4 downloads.openpli.org
Start: 2023-09-23T11:54:37+0200
HOST: ds9           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1    0.0%    10    0.3   0.3   0.2   0.4   0.1
  2.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 213.51.195.45  0.0%    10    8.9  11.3   8.0  18.1   3.6
  4.|-- 213.51.5.26    0.0%    10   17.9  12.3   9.4  17.9   2.6
  5.|-- 213.51.64.190  0.0%    10    9.3   9.9   9.3  11.3   0.6
  6.|-- 91.121.131.85  0.0%    10   15.0  23.3  10.5  50.9  16.1
  7.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- 54.36.50.81   10.0%    10   26.6 140.5  25.9 1047. 340.1
 11.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 13.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 16.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 17.|-- 51.195.116.98  0.0%    10   26.2  28.2  25.5  33.8   2.6
gertjan@ds9:~$ mtr -Twn -4 downloads.openpli.org
Start: 2023-09-23T11:55:13+0200
HOST: ds9           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1   30.0%    10  7202. 3196.   0.3 7202. 2908.3
  2.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 213.51.195.45 30.0%    10  7086. 2033.   9.9 7086. 2611.0
  4.|-- 213.51.5.26   40.0%    10  7286. 2401.  10.0 7286. 2757.5
  5.|-- 213.51.64.190 20.0%    10   12.0  11.0   9.8  13.3   1.3
  6.|-- 91.121.131.85 90.0%    10  7258. 7258. 7258. 7258.   0.0
  7.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 13.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???           100.0     9    0.0   0.0   0.0   0.0   0.0
 16.|-- ???           100.0     9    0.0   0.0   0.0   0.0   0.0
 17.|-- 51.195.116.98 25.0%     8   29.3 1206.  25.7 3062. 1484.6
gertjan@ds9:~$ mtr -Twn -4 downloads.openpli.org
Start: 2023-09-23T11:55:55+0200
HOST: ds9            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1     0.0%    10    0.3   0.3   0.2   0.3   0.1
  2.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 213.51.195.45   0.0%    10   10.2  12.5   8.1  30.5   6.5
  4.|-- 213.51.5.26     0.0%    10   12.7  10.3   9.3  12.7   1.0
  5.|-- 213.51.64.190   0.0%    10   11.2  13.4   8.8  33.0   7.2
  6.|-- 91.121.131.85   0.0%    10   13.9  12.3  10.6  13.9   1.2
  7.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- 213.186.32.210  0.0%    10   51.8  41.5  18.2 139.7  41.1
 11.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 13.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 16.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 17.|-- ???            100.0    10    0.0   0.0   0.0   0.0   0.0
 18.|-- 51.178.16.136   0.0%    10   19.8  20.0  18.4  21.5   0.8
gertjan@ds9:~$ mtr -Twn -4 downloads.openpli.org
Start: 2023-09-23T11:56:25+0200
HOST: ds9           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1   70.0%    10  7234. 2411.   0.3 7234. 4176.9
  2.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 213.51.195.45 80.0%    10  7120. 7171. 7120. 7223.  72.2
  4.|-- 213.51.5.26   90.0%    10   12.8  12.8  12.8  12.8   0.0
  5.|-- 213.51.64.190 80.0%    10  7087. 3549.  11.9 7087. 5003.1
  6.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
gertjan@ds9:~$ mtr -Twn -4 downloads.openpli.org
Start: 2023-09-23T11:56:52+0200
HOST: ds9           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1   10.0%    10    0.2   0.3   0.2   0.4   0.1
  2.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- 213.51.195.45  0.0%    10   19.0  14.3   9.3  25.5   5.5
  4.|-- 213.51.5.26    0.0%    10    9.7  10.6   9.3  12.5   1.0
  5.|-- 213.51.64.190 10.0%    10   13.0  11.1   9.0  13.0   1.4
  6.|-- 91.121.131.85 20.0%    10   13.0  13.6  11.9  18.4   2.1
  7.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 10.|-- 54.36.50.83   30.0%    10  1038. 316.3  27.6 1038. 490.7
 11.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 13.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 14.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 16.|-- ???           100.0    10    0.0   0.0   0.0   0.0   0.0
 17.|-- 51.195.116.98 10.0%    10   27.9  27.7  26.1  30.3   1.3

Ik zie overigens ook dit:

downloads.openpli.org.  1653    IN      A       51.178.16.136
downloads.openpli.org.  1653    IN      A       51.195.116.98
 

downloads.openpli.org is blijkbaar multihomed ?

 

Een traceroute naar 51.195.116.98 levert 17 hops op, maar soms 16, naar 51.178.16.136 is het 18 hops, en die blijft met een aantal tests ook 18.

Edited by gjstroom, 23 September 2023 - 11:09.

[luisteraar]

klopt als een link niet werkt wordt een andere route genomen.

het niet werken kan o.a. aan storing en overbelasting liggen

[gjstroom]

klopt als een link niet werkt wordt een andere route genomen.

het niet werken kan o.a. aan storing en overbelasting liggen

Ben ik niet met je eens, dan zou er een veel lagere ttl op het dns record moeten staan.Nu lijkt het op round-robin loadbalancing, maar als nu bv 1 van de 2 ip adressen niet thuis geeft, dan krijg je dus een timeout...

Met retries kan je dan door dns resolving het andere ip adres krijgen maar met zo'n hoge ttl gaat die vlieger hier niet op.

Het is ook de vraag hoe opkg hier dan mee omgaat om iets te downloden, er wordt downloads.openpli.org geresolved en er komen 2 ip adressen terug. Meestal wordt dan alleen de 1e gebruikt.

 

Ik weet verder niet hoe downloads.openpli.org is opgebouwd, ik doe blond dit:

http://downloads.ope...op/all/Packages  werkt
http://51.195.116.98...op/all/Packages  geeft File not found!
http://51.178.16.136...op/all/Packages  geeft nginx error!

 

Dus het lijkt er op dat er iets met een nginx webserver/proxy wordt gedaan ? Nignx zal ogetwijfeld via de host headers werken en niet op ip, vandaar dat de poging op ip adres niet werkt.

Edited by gjstroom, 23 September 2023 - 11:33.

[luisteraar]

De ttl (time to live) staat in de IP protocol die bepaald

de afzender dus je zelf.

De tooltjes om de routes te vinden werken hier op je start met

ttl 1 die stuur je naar je modem die zegt jou ttl is op en stuurt

je een icmp packet.

dan uitzenden ttl 2 je modem laat die door en zet ttl op 1 en

packet gaat naar provider maar provider stuurt icmp terug omdat ttl op is.

De internode werkt met hele andere protocollen.

Edited by luisteraar, 23 September 2023 - 11:32.

[gjstroom]

De ttl (time to live) staat in de IP protocol die bepaald

de afzender dus je zelf.

De tooltjes om de routes te vinden werken hier op je start met

ttl 1 die stuur je naar je modem die zegt jou ttl is op en stuurt

je een icmp packet.

dan uitzenden ttl 2 je modem laat die door en zet ttl op 1 en

packet gaat naar provider maar provider stuurt icmp terug omdat ttl op is.

De internode werkt met hele andere protocollen.

Ik heb het over ttl van het dns record !

mtr wordt in tcp mode gebruikt...

Edited by gjstroom, 23 September 2023 - 11:37.

[luisteraar]

 

De ttl (time to live) staat in de IP protocol die bepaald

de afzender dus je zelf.

De tooltjes om de routes te vinden werken hier op je start met

ttl 1 die stuur je naar je modem die zegt jou ttl is op en stuurt

je een icmp packet.

dan uitzenden ttl 2 je modem laat die door en zet ttl op 1 en

packet gaat naar provider maar provider stuurt icmp terug omdat ttl op is.

De internode werkt met hele andere protocollen.

mtr wordt in tcp mode gebruikt...

 

Maar boven tcp zit de ip waar de ttl in zit

[gjstroom]

 

 

De ttl (time to live) staat in de IP protocol die bepaald

de afzender dus je zelf.

De tooltjes om de routes te vinden werken hier op je start met

ttl 1 die stuur je naar je modem die zegt jou ttl is op en stuurt

je een icmp packet.

dan uitzenden ttl 2 je modem laat die door en zet ttl op 1 en

packet gaat naar provider maar provider stuurt icmp terug omdat ttl op is.

De internode werkt met hele andere protocollen.

mtr wordt in tcp mode gebruikt...

 

Maar boven tcp zit de ip waar de ttl in zit

 

Laat maar, ik heb geen zin om hier verder een discussie te gaan voeren. Zoals ik al heb ge-edit, ik heb het over ttl van het dns record.
Jouw verdere verhaal over ttl en icmp daar kan ik geen touw aan vastknopen.

[luisteraar]

Het hele transport van ip naar ip staat los

van dns entry's.

De ttl is wel van belang om te kunnen transporteren

[WanWizard]

Ik zie overigens ook dit:
downloads.openpli.org.  1653    IN      A       51.178.16.136
downloads.openpli.org.  1653    IN      A       51.195.116.98
 
downloads.openpli.org is blijkbaar multihomed ?

 
Nee, het zijn twee servers in een DNS round robin.
 
Je kunt ze individueel benaderen via hun eigen hostname, download1 en download2.
 
De ene staat in Frankfurt, de andere in Gravelines (boven Calais). Dus als je provider geen peering heeft, of de peering pijp overbelast is, dan is het logisch dat je verschillende netwerk paden ziet.
 
En dat is nu net de kern van het probleem met de verbinding van KPN naar OVH.
 

Ik weet verder niet hoe downloads.openpli.org is opgebouwd, ik doe blond dit:
http://downloads.ope...op/all/Packages  werkt
http://51.195.116.98...op/all/Packages  geeft File not found!
http://51.178.16.136...op/all/Packages  geeft nginx error!
 
Dus het lijkt er op dat er iets met een nginx webserver/proxy wordt gedaan ? Nignx zal ogetwijfeld via de host headers werken en niet op ip, vandaar dat de poging op ip adres niet werkt.

 

Dat weet ik dan weer wel .

 

Op beide draait nginx als caching proxy. De upstream is een interne server waar de deploy van de buildservers op staat. De reden daarvoor is simpel, de interne server heeft geen bandbreedte voor de meer dan 2 miljoen hits die deze servers dagelijks voor hun kiezen krijgen.

 

Wat je echter probeert te doen werkt niet, er draait namelijk nog veel meer op die servers, je kunt ze niet op IP benaderen, je moet de hostname gebruiken (download1.openpli.org of download2.openpli.org).

 

Een 404 Not Found is de correcte response voor je pogingen op IP.

[WanWizard]

Onze provider heeft overigens wat monitoring opgezet op een van de servers, richting het public IP van Frenske.

 

Nu is een netwerk full duplex, en dus zegt meten van A naar B niet zo veel over B naar A, maar het valt wel op dat soms maar 1 op de 3 pakketten door komt:

 

Attached Files

•  Screenshot from 2023-09-23 13-45-37.png   34.02KB   2 downloads

[luisteraar]

Hoe het met de peerings/betalen zit weet ik niet.

Kan me moeilijk voorstellen dat kpn met alle providers

van de wereld een overeenkomt moet maken.

Ik weet alleen uit de hele begintijd van internet het netwerk was open

wilde je er op kon je een kabel leggen en evt hardware plaatsen .

Zo is in die tijd een link gekomen tussen ensenada mexico en ucsd californie

waarbij ik betrokken was.

[WanWizard]

Ik gelukkig wel.

 

Begin jaren '90 meegebouwd aan het internationale ATM netwerk van General Electric (bij GEIS), voor Interoute rond de eeuwwisseling een 18000km WDM netwerk opgebouwd, en de laatste 11 jaar voor mijn AO als adviseur van de Vlaams minister voor Bestuurszaken verantwoordelijk geweest voor het Netwerk van de Vlaamse Overheid, hun datacenters, en de interne Vlaamse ISP (die levert netwerk diensten aan andere overheidsonderdelen en agentschappen, is nu Digitaal Vlaanderen).

 

In de basis moet je als ISP poort capaciteit aankopen bij een of meerdere internet exchanges. Die capaciteit moet je echter delen met alle andere gebruikers op die IX, en staat niet in verhouding tot de maximale poort capaciteit.

 

ISP's kunnen onderling een peering overeenkomst afsluiten als ze beide een aansluiting hebben op de IX, er is dan directe BGP routing tussen beide AS'sen, en de IX zelf is daarmee kortgesloten. Of dat geld kost hangt messtal af van het verkeer dat er over moet gaan. Als dat een beetje gebalanceerd is, dan gaat het meestal met gesloten beurs.

De peering policy van OVH is publiek (https://peering.ovh.net/), KPN is erg vaag, zelfs de peeringdb is niet up to date. En als je dan dit leest: https://www.a2b-inte...ernet-afnemers/

[luisteraar]

interssant lees voer wel een beetje getint.
rond 1990 was hier niet veel over internet.
surfnet hactic knoware was alles uit mijn hoofd.
toen waren ook bandbreedte problemen.
had links naar tue fh-juelich en az leuven.
En zat thuis servers van cicese in mexico te
configureren ,wat een leuke tijd en veel in
vliegtuig gezeten.
Toch ben ik van mening dat het probleem
niet bij kpn zit maar de link aanbieder
tussen kpn en downloads.openpli
org

[Tech]

En dus aan de afspraken welke KPN met die netwerkbeheerders gemaakt heeft, dat is namelijk de hele essentie van dit onderzoek.

[Frenske]

Een eerste test waarbij ik verbinding maakte via NordVPN leerde dat er 0% data loss bleek. Helaas is de doorgifte van NordVPN nogal geknepen maar voor zover ik kan zien is het resultaat véél beter. Waarom er geen tussenstations getoond worden met een identieke opdracht gaat mijn pet te boven maar kenners hebben daar mogelijk wel een verklaring voor. NordVPN beperking wellicht?
 

openpli develop vuuno4kse                                                       
                                                                                
vuuno4kse login: root                                                           
Last login: Sat Sep 23 23:48:21 CEST 2023 on pts/1                              
root@vuuno4kse:~# mtr -Twn downloads.openpli.org                                
Start: 2023-09-24T09:23:00+0200                                                 
HOST: vuuno4kse     Loss%   Snt   Last   Avg  Best  Wrst StDev                  
  1.|-- 51.178.16.136  0.0%    10    6.1   6.2   6.1   6.2   0.0                

[luisteraar]

die werken met ip ip encapselation
dan zie je alleen eind punten.
doe maar eens een test op een site
in de ukraine je zal zo goed als niets zien.

[luisteraar]

En dus aan de afspraken welke KPN met die netwerkbeheerders gemaakt heeft, dat is namelijk de hele essentie van dit onderzoek.

We zijn er nu ook achter gekomen gekomen dat ziggo met het

zelfde probleem zit op bepaalde tijden kom 2/3 van hun packets niet aan.

 

Je kan het zo zien

Ik heb een audi (lees kpn) kan in 2 uur van maastricht naar

amsterdam rijden.

In de praktijk is het 3 uur omdat teveel auto's (lees tcpip pakjes) op de straat zijn.

Probleem is niet de auto maar de drukte

Edited by luisteraar, 24 September 2023 - 11:04.

[Arie_K]

Ik heb ook KPN.   ovh.png   137.84KB   2 downloads

Vanmorgen om +/- 10.40 geflashed naar RC9 dat duurde erg lang, +/- 11.05 klaar.

Er waren veel timeouts en foutmeldingen, zie log   autoinstall-25minuten.txt   31.87KB   1 downloads

Omdat er zoveel niet geïnstalleerd was, nog een poging gedaan en die ging wel goed binnen +/- 5 minuten klaar.   autoinstall.log   32.13KB   0 downloads

Het gaat dus niet lekker met KPN.

 

Is het niet mogelijk, als er zoveel foutmeldingen zijn, dat autoinstall aan het eind aangeeft dat de backup terugzetten niet gelukt is en dan vraagt of het nog een keer moet proberen?

 

[WanWizard]

Het mislukken van een autoinstall is niet echt kritisch, je kunt gewoon in het menu naar "autobackup", dan de menu knop in drukken, en autoinstall nogmaals draaien.

[WanWizard]

die werken met ip ip encapselation
dan zie je alleen eind punten.
doe maar eens een test op een site
in de ukraine je zal zo goed als niets zien.

 

Houd nu toch eens op met je bek een douw geven aub.

 

Frenkse zegt dat hij maar 1 hop ziet, het eindpoint. Denk je nu werkelijk dan onze servers tevens eindpunten zijn van NordVPN? Laat staan dat een referentie naar Ukraine van belang is.

 

Nee dus, en derhalve is je antwoord van nul en generlei waarde. Als je niet weet waarom de hops tussen het NordVPN eindpoint en het IP in kwestie niet getoond worden, onthoud je dan van commentaar, ipv het topic te vervuilen?