121 replies to this topic

[WanWizard]

Fingers crossed dan maar.

 

Als 't zo blijft hoeven we in ieder geval geen kosten te maken om servers te laten verhuizen.

[luisteraar]

achter af gezien is het probleem
weg en was het geen peering probleem
maar een hardware link probleem.
Door een andere route te nemen werkt
het weer goed.
inderdaad hopelijk blijft het nu goed

[Frenske]

achter af gezien is het probleem
weg en was het geen peering probleem
maar een hardware link probleem.
Door een andere route te nemen werkt
het weer goed.
inderdaad hopelijk blijft het nu goed

Ik ga maar niet in discussie over het effect van toegevoegde peering of omleiden van een route. Feitelijk komt dit op hetzelfde neer. Technisch is dit wellicht verschillend maar het effect is helder. Wat wel zeer teleurstellend is geweest, dat niemand maar dan ook niemand van eender welke klantenservice, consument of zakelijk, behoudens Bart_Z, zich heeft bekommerd om de gevolgen van alle gebruikers van KPN met een Enigma ontvanger. Daar ga ik nog wel werk van maken dat de klantenservices feitelijk aangeeft “dit gaat mijn pet te boven en daarmee houdt het op”. Ook een medewerker van de KPN klachtenafhandeling besluit hiermee hun reactie. Daarop reageer ik “en wat gaat er nu gebeuren?”. Het antwoord is net zo simpel als mogelijkerwijs de betreffende medewerker, “ja, uhm, niets”. Prima service KPN. NOT dus.

[XRayhTec]

Los van het feit dat MTR iets anders lijkt aan te geven moet ik wel hier vermelden dat ik weer full speed een box kan (her)flashen incl. restoren van een backup met plug-ins en picons in minder dan 4 minuten. Het probleem lijkt opgelost vanaf 17:00 vandaag.

 

Kan ik hier uit afleiden dat het mtr tooltje niet geschikt was voor jouw onderzoek?

Of worden de gegevens van het tooltje niet correct geinterpreteerd?

[luisteraar]

de gegevens van mtr traceroute tracert enz moet je met een korreltje

zout nemen.

Wat doen ze :

Ze versturen een packet men een beperkte levensduur (de ttl in de ip header)

de packet gaat door de routers tot een router die vast stelt de ttl is overschreden

en meld het met een icmp terug.

Niet iedere router houd zich aan het protocol en geeft een terug melding.

[Frenske]

 

Los van het feit dat MTR iets anders lijkt aan te geven moet ik wel hier vermelden dat ik weer full speed een box kan (her)flashen incl. restoren van een backup met plug-ins en picons in minder dan 4 minuten. Het probleem lijkt opgelost vanaf 17:00 vandaag.

 

Kan ik hier uit afleiden dat het mtr tooltje niet geschikt was voor jouw onderzoek?

Of worden de gegevens van het tooltje niet correct geinterpreteerd?

 

 

De onderzoeken zijn door Wanwizard uitgevoerd. De waarde van dit onderzoek kan ik lastig interpreteren. 100% dataloss lijkt mij dan niet goed. 
Ik denk dat MTR goed is om de afgelegde route te bepalen. Wij hebben ook getest met Eperf3. 

[luisteraar]

Hoe dan ook de hulp mod mod forum kpn heeft goed gewerkt "dank je kpn"

Vanuit brussel loopt het ook goed de route via frankfurt wordt gemeden.

Ik zou willen weten hoe nu de route vanaf kpn loopt ? kan iemand het hier posten ?

 

de route hier

                                                     Loss%   Snt   Last   Avg  Best  Wrst StDev

  1.|-- mymodem                            0.0%    10    1.8   1.7   1.6   2.2   0.2

  2.|-- 10.24.49.152                       0.0%    10    9.8   9.6   9.1  10.7   0.4

  3.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0

  4.|-- ae-64-100.ibrstr6.isp.proximus.be  0.0%    10   13.7  16.4  13.2  28.3   4.6

  5.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0

  6.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   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.|-- be101.gra-g1-nc5.fr.eu             0.0%    10   17.1  34.6  16.9 155.6  43.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.|-- ???                               100.0    10    0.0   0.0   0.0   0.0   0.0

 18.|-- cdn1.hosting.flexcoders.eu         0.0%    10   16.5  17.0  16.5  17.4   0.3

[WanWizard]

Je kunt een MTR beter laten lopen met -T voor TCP pakketten, omdat routers inderdaad ICMP als eerste zullen droppen. De laatste hops zijn allemaal software-based routers binnen een virtualisatie platform, dus daar kan ik met dat wel voorstellen.
Kans is ook groot dat die wellicht niet eens volledige routing capaciteit hebben, en dus gewoon niet antwoorden op pakketten van buiten.

 

Dat doen ze echter niet (of zelden) default en altijd, dus als er dropt zijn, dan is dat zeker een indicatie dat de router niet meer voldoende lucht heeft om een reply op de ICMP te sturen.

 

Ik gebruik zelf altijd

mtr -o 'J M X LSR NA B W V' -T -wzbc 50 <host>

naast het gebruik van TCP en tests over een langere periode geeft dit ook AS informatie:

 

Zoals die gerrit al post op het KPN forum: ze hebben gewoon wat zitten kloten met routing, en dat is een klein pleistertje plakken op een groot probleem.

 

Als je test met bovenstaand commando, dat 50 runs doet, dan zie je ook dat de data nog steeds zowel via OpenTransit als via Liberty Global gerouteerd wordt, naar een zelfde destinatie.

 

Dus ik vraag me ernstig af of, wat er waar hier aan welke knop gedraaid is. Want routering is duidelijk niet aangepast, zoals gesteld.

[luisteraar]

 

 

Dus ik vraag me ernstig af of, wat er waar hier aan welke knop gedraaid is. Want routering is duidelijk niet aangepast, zoals gesteld.

Uit de oude metingen bleek duidelijk dat het mis ging tussen Frankfurt en Frankrijk.

Bij B zie ik geen Frankfurt meer in de trace.

Daarom interessert het mij of route vanuit kpn nu ook zonder franfurt loopt.

 

Klooien aan routes is wel eens nodig als een link storing heeft en autorouting werkt niet meer goed moet

je met de hand een omleiding maken

Edited by luisteraar, 29 September 2023 - 13:34.

[WanWizard]

Dan moet je in ieder geval download2 testen, want die staat in frankfurt. Download1 staat in Gravelines, die komt niet bij duitsland in de buurt...

 

Er valt in BGP niet zo bijzonder veel te klooien, dat is prefix routing, het enige wat KPN onder controle heeft is de next hop op hun BGP peering router, of eventueel op de NL-IX zelf (maar dat zou ik al erg dubieus vinden). De rest is aan het AS waarnaar gerouteerd wordt.

 

Carrier networking is niet te vergelijken met gewoon (enterprise) networking, dat is een hele andere tak van sport.

[luisteraar]

de route naar download2 loopt van bru  naar frankrijk dan frankfurt met weer

de nodige losses rond frankfurt

 

AS16276  be105.rbx-g1-nc5.fr.eu (2001:41d0::661)                  2039  1401  7303   4.0%    50    48  3060. 1016.   16.8  7321.  1679.8

     AS16276  rbx-g4-nc5.be.eu (2001:41d0::2763)

     AS16276  rbx-g3-nc5.be.eu (2001:41d0::2761)

     AS16276  be105.rbx-g2-nc5.fr.eu (2001:41d0::38e)

 10. AS16276  be104.fra-fr5-sbb2-nc5.de.eu (2001:41d0::c75)            4180  1861  7286  20.0%    50    40  7238. 1399.   24.4  7310.  2225.9

     AS16276  fra-fr5-sbb2-nc5.de.eu (2001:41d0::25ec)

     AS16276  be104.fra-fr5-sbb1-nc5.de.eu (2001:41d0::61b)

     AS16276  fra-fr5-sbb1-nc5.de.eu (2001:41d0::25f2)

 11. AS16276  fra1-lim1-g1-8k.de.eu (2001:41d0::dc9)                   3035  2434  7264  48.0%    50    26  3062. 2024.   26.6  7293.  2495.0

     AS16276  fra1-lim1-g2-8k.de.eu (2001:41d0::c01)

[WanWizard]

Dat is dus ook via Orange.

 

Die hebben een connectie op de OVH POP in Roubaix (de rbx routers, en vandaar naar Frankfurt (de fra routers). Roubaix is nu niet direct een belangrijke POP met veel interconnectiviteit. Maar als ik de weathermaps bekijk zie ik niet echt veel drukte op de links.

 

Nu test je wel op IPv6, en dat kan weer heel anders lopen dan IPv4.

[luisteraar]

Ik kijg hoe langer hoe meer twijfel aan mtr over de berekende waarden

 

Doe ik mtr krijg ik lossen binnen belgacom net.

Die ik ping test loopt het als een sneltrein

 

ping -c 10 51.178.16.136

PING 51.178.16.136 (51.178.16.136) 56(84) bytes of data.

64 bytes from 51.178.16.136: icmp_seq=1 ttl=48 time=16.8 ms

64 bytes from 51.178.16.136: icmp_seq=2 ttl=48 time=16.6 ms

64 bytes from 51.178.16.136: icmp_seq=3 ttl=48 time=16.6 ms

64 bytes from 51.178.16.136: icmp_seq=4 ttl=48 time=16.5 ms

64 bytes from 51.178.16.136: icmp_seq=5 ttl=48 time=16.8 ms

64 bytes from 51.178.16.136: icmp_seq=6 ttl=48 time=16.9 ms

64 bytes from 51.178.16.136: icmp_seq=7 ttl=48 time=16.9 ms

64 bytes from 51.178.16.136: icmp_seq=8 ttl=48 time=16.9 ms

64 bytes from 51.178.16.136: icmp_seq=9 ttl=48 time=16.8 ms

64 bytes from 51.178.16.136: icmp_seq=10 ttl=48 time=16.7 ms

 

--- 51.178.16.136 ping statistics ---

10 packets transmitted, 10 received, 0% packet loss, time 25ms

rtt min/avg/max/mdev = 16.468/16.734/16.893/0.211 ms

 

 

 

                                                                                           Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg   Best   Wrst  StDev

  1. AS???    mymodem (192.168.1.1)                                  1.0   2.9  127.   0.0%    50    50    1.8   4.5    1.6  128.8   17.9

  2. AS???    10.24.49.152                                           0.3   1.2  19.3   0.0%    50    50   10.2  10.3    9.2   28.6    2.8

  3. AS5432   lg-10-304.msr41gre7.isp.belgacom.be (91.183.241.201)  4019  3155  7080  66.0%    50    17  3043. 2809.   12.0  7154.  2714.4

  4. AS5432   ae-64-100.ibrstr6.isp.proximus.be (91.183.241.200)     0.1   1.9  25.2   0.0%    50    50   13.4  14.5   13.0   38.6    4.4

  5. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

  6. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

  7. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

  8. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

  9. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 10. AS16276  be101.gra-g1-nc5.fr.eu (91.121.131.27)                 0.6  38.3  179.   0.0%    50    50   16.8  45.1   16.7  195.8   50.6

 11. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 12. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 13. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 14. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 15. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 16. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 17. AS???    ???                                                    0.0   0.0   0.0  100.0    50     0    0.0   0.0    0.0    0.0    0.0

 18. AS16276  cdn1.hosting.flexcoders.eu (51.178.16.136)             0.2   1.7  12.9   0.0%    50    50   16.8  17.9   16.6   29.7    2.8

 

[WanWizard]

Hier is niks mis mee, die tussenliggende hops reageren gewoon niet, of kunnen niet reageren.

 

Je kunt hooguit wat vinden van de trace reactie van de belgacom router.

[luisteraar]

als je goed gekeken had binnen
belgacom net 60 % loss daar geloof
ik niets van .
uit de ping test lijkt dat route prima is.

[WanWizard]

60% loss bekent niet meer of minder dan dat er maar op 40% van de requests een antwoord komt. Dat staat volledig los van een ping, die ziet die router niets eens...

[luisteraar]

bij een ping gaan de packets wel door
de router en honderd % komt terug
zonder een loss.
die 60? kan niet kloppen.
zou ook onwaarscheinlijk zijn
omdat het binnen zelfde datacenter zit.

Edited by luisteraar, 29 September 2023 - 19:05.

[WanWizard]

Wederom geef je weer blijk van het feit dat je niet weer hoe het werkt.

[luisteraar]

weet je wat ping doet ?


bij ping wordt wordt een icmp frame naar de
de bestemming gestuurt in dit geval downloads.opepli.org.
downloads.openpli.org stuurt dan een antwoord
aan de afzender.
de frame gaat dus door alle servers die er
tussen zitten en dat 2 keer door alle
servers naar downloads.opepli...
en dat zonder en loss.

Edited by luisteraar, 29 September 2023 - 19:26.

[Tech]

Hoever wil je nu nog gaan afwijken van het originele topic?