Userbase

Hallo,

Heeft er soms nog iemand last van hoge pingwaardes en/of nogal veel fouten als bij een traceroute ?
Heb hier eigenlijk nooit last van gehad maar tegenwoordig valt dit nogal geregeld voor.
Modemwaarden op zich zijn voor de rest perfect in orde.

Wel extra handig als je er een voorbeeld zou bijdoen he

Bijvoorbeeld een stukje van de trace naar http://www.audi.be

...
7 15 ms 15 ms 15 ms bru-bix-h2-g3-12.car.belbone.be [80.84.18.67]
8 15 ms 15 ms 15 ms verizon.bnix.net [194.53.172.78]
9 16 ms 15 ms 15 ms 322.at-5-3-0.XT1.BRU2.ALTER.NET [194.7.61.1]
10 16 ms 15 ms 15 ms POS0-0.GW3.BRU2.ALTER.NET [146.188.2.82]
11 * ube01368.be.customer.alter.net [212.190.126.162] rapporten: Het doelnetwerk is niet bereikbaar.
...
of naar http://www.detelegraaf.nl
...
6 18 ms 41 ms 15 ms bru-22-r5-t3-2.car.belbone.be [80.84.18.7]
7 29 ms 105 ms 93 ms prs-bgc-r3-t2-1.car.belbone.be [80.84.18.154]
8 29 ms 29 ms 29 ms abovenet.panap.fr [62.35.254.35]
9 30 ms 29 ms 45 ms xe-0-1-0.mpr1.fra3.de.above.net [64.125.31.234]

10 31 ms 31 ms 31 ms xe-4-1-0.mpr1.ams1.nl.above.net [64.125.24.9]
11 29 ms 29 ms 29 ms xe-3-0-0.er1.ams1.nl.above.net [64.125.28.94]
12 31 ms 31 ms 31 ms k269.telegraaf.ams1.nl.above.net [82.98.242.30]

13 32 ms 31 ms 33 ms to-sara.am.core.telegraaf.net [217.196.40.74]
14 32 ms 33 ms 32 ms gw-core.telegraaf.net [217.196.45.1]
15 * * * Time-out bij opdracht.
16 * * * Time-out bij opdracht.
17 * * * Time-out bij opdracht.
18 * * * Time-out bij opdracht.
19 * * * Time-out bij opdracht.
enz. enz.
...

Tijden vallen nu op dit moment mee maar soms steekt er zo eens eentje tussen van +500 ms.

Waardes van de modem:

ADSL STATUS

ADSL Status Infomation
Showtime Firmware Version: 3.27
Line State: SHOWTIME
Modulation: G.dmt
Annex Mode: ANNEX_A
Startup Attempts: 1
Max Tx Power: -38 dBm/Hz
CO Vendor: ALCATEL_NETWORK


Downstream Upstream
SNR Margin 31.6 24.0 dB
Line Attenuation 5.9 6.0 dB
Errored Seconds 0 0
Loss of Signal 0 0
Loss of Frame 0 0
CRC Errors 0 0
Data Rate 4640 512 kbps
Latency FAST FAST

(en wachtend op een verhoging van de snelheid )

Je bent niet de enige. Zowat iedereen die Scarlet, Belgacom, Dommel gebruikt heeft er last van.

Dat heeft er niks mee te maken, ik heb net eens dezelfde traceroutes geprobeerd vanop een UK netwerk en krijg hetzelfde resultaat. Security wise antwoorden niet alle systemen op pingcommando's. En dat zal hier wel het probleem zijn. Je geraakt toch tot bij de telegraaf op het netwerk en de rest willen ze niet dat je ontdekt, zo simpel is het.

Er wordt hier nogal snel op de messenger en de pianist geschoten, vind ik.

J.

Die resultaten zijn toch zo slecht niet, 15 ms en 32 ms lijken mij redelijke waardes.

Ik zit bij Telenet en haal volgende waardes:
http://www.audi.be: 20 ms
http://www.detelegraaf.nl: 14 ms

Sidon schreef:Tijden vallen nu op dit moment mee maar soms steekt er zo eens eentje tussen van +500 ms.

Dat kan een probleem zijn maar dat is het niet noodzakelijk.
Het heeft allemaal te maken met de prioriteit van de routers.
De prioriteit van een ping ligt gewoon lager dan TCP/UDP data.

Dus om de latency van een router te kennen moet je kijken naar de tijden van de volgende router (hop).
Dus in het voorbeeld van http://www.telegraaf.be heb je op prs-bgc-r3-t2-1.car.belbone.be [80.84.18.154] voor 2 packetjes vrij hoge RTT waarden (105 ms en 93 ms).
Dit wil zeggen dat deze hop respectievelijk 105 ms en 93 ms nodig had om je ping te beantwoorden.

Echter de volgende hop (abovenet.panap.fr [62.35.254.35]) slaagt erin om jouw ping te beantwoorden in 29 ms.
M.a.w. de prs-bgc-r3-t2-1.car.belbone.be was snel genoeg om de data door te sturen naar abovenet.panap.fr maar was trager om de ping te beantwoorden en dat is gewoon omdat de prioriteit van de ping commando's zo laag is.

'k Heb nu een misschien een beter voorbeeldje te pakken (fenomeen doet zich dus niet constant voor).
Wederom een stukje uit een trace baar http://www.detelegraaf.nl

2 36 ms 15 ms 11 ms gateway.dyn1.antwerpen3.schedom-europe.net [83.1
01.77.1]
3 4359 ms 1036 ms 978 ms vlan202.largo-matisse.bru.schedom-europe.net [83
.101.0.194]
4 67 ms 150 ms 40 ms bru-22-r15-g2-1.car.belbone.be [80.84.21.54]
5 195 ms 155 ms 63 ms 94.102.162.26
6 * * * Time-out bij opdracht.
7 24 ms 41 ms 34 ms prs-bgc-r3-t2-1.car.belbone.be [80.84.18.154]
8 29 ms 29 ms 29 ms abovenet.panap.fr [62.35.254.35]
9 30 ms 29 ms 27 ms xe-0-1-0.mpr1.fra3.de.above.net [64.125.31.234]

10 48 ms 32 ms 29 ms xe-4-1-0.mpr1.ams1.nl.above.net [64.125.24.9]
11 * * 772 ms xe-3-0-0.er1.ams1.nl.above.net [64.125.28.94]
12 39 ms 32 ms 33 ms k269.telegraaf.ams1.nl.above.net [82.98.242.30]

13 54 ms 34 ms 31 ms to-sara.am.core.telegraaf.net [217.196.40.74]
14 32 ms 31 ms 31 ms gw-core.telegraaf.net [217.196.45.1]

Sidon schreef:3 4359 ms 1036 ms 978 ms vlan202.largo-matisse.bru.schedom-europe.net [83
.101.0.194]
14 32 ms 31 ms 31 ms gw-core.telegraaf.net [217.196.45.1]

Ik zie nog altijf het probleem niet .

Hop 3 (vlan202.largo-matisse.bru.schedom-europe.net) reageert traag op je ping maar uiteindelijk gaat de echte data (TCP/UDP) er heel snel door want anders zou hop 14 (gw-core.telegraaf.net) niet zo snel kunnen reageren.

Als dit zich nog eens voordoet, doe dan eens een ping direct op 217.196.45.1 en kijk eens wat de resultaten zijn.

Pingen naar 217.196.45.1 met 32 byte gegevens:

Antwoord van 217.196.45.1: bytes=32 tijd=50 ms TTL=56
Time-out bij opdracht.
Antwoord van 217.196.45.1: bytes=32 tijd=103 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=31 ms TTL=56

... en een tweede maal ...

Antwoord van 217.196.45.1: bytes=32 tijd=108 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=55 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=140 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=123 ms TTL=56

... en een derde maal ...

Antwoord van 217.196.45.1: bytes=32 tijd=314 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=30 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=57 ms TTL=56
Antwoord van 217.196.45.1: bytes=32 tijd=31 ms TTL=56

Ik verdenk hop 3 (vlan202.largo-matisse.bru.schedom-europe.net) dus ping eens naar hop 4 (80.84.21.54).
Maar doe eerst een ping naar 217.196.45.1 want bovenstaande werkt maar als we zeker zijn dat er op dat moment problemen zijn met de "volledige" route.

Tja...

Astralon schreef:Maar doe eerst een ping naar 217.196.45.1

Der is wel niet enkel een probleem naar die bestemming, als het er is, is het naar eender waar. Het valt me nu ook wel op dat wanneer ik op die momenten een trace doe er precies toch iets mis is bij het begin van de route, bij hop 3 dus (ping naar daar geeft dan time out, 100% verlies). 'k Snap alleen niet goed waarom enkel ik hier last mee zou hebben.

Zoals hierboven reeds gezegd: dat is puur omdat die node ping requests weigert.

Niets aan de hand, zag 1x dat 94.102.162.26 (belbone.be) 1.8 sec nodig had om antwoord te geven.
De drukke routers zijn goed te zien door average en current met elkaar te vergelijken, maar ieder heeft voldoende tijd om het verkeer door te geven want de eindbestemming gw-core.telegraaf.net heeft weinig verschil tussen avg en cur.
Packetloss heb ik niet gezien.
Wat ook op valt dat de tijden naar hop 2 bijzonder hard zijn, dit is het vdsl2 Belgacom netwerk.
Maar ook tot hop3 heb ik de afgelopen weken geen problemen gezien (Dommel), een teken dat deze voldoende ruim bemeten zijn.

Goztow schreef:Zoals hierboven reeds gezegd: dat is puur omdat die node ping requests weigert.

Maar waarom de ne keer dan wel en de andere keer niet ?
Nu gaat alles heel vlotjes en geeft een ping naar daar het volgende

Pingen naar 83.101.0.94 met 32 byte gegevens:

Antwoord van 83.101.0.94: bytes=32 tijd=13 ms TTL=62
Antwoord van 83.101.0.94: bytes=32 tijd=13 ms TTL=62
Antwoord van 83.101.0.94: bytes=32 tijd=13 ms TTL=62
Antwoord van 83.101.0.94: bytes=32 tijd=14 ms TTL=62

Ping-statistieken voor 83.101.0.94:
Pakketten: verzonden = 4, ontvangen = 4, verloren = 0
(0% verlies).De gemiddelde tijd voor het uitvoeren van één bewerking in mill
iseconden:
Minimum = 13ms, Maximum = 14ms, Gemiddelde = 13ms

Als de node veel werk heeft, zal hij prioriteiten stellen.

Ik heb hier nog geen antwoord gezien van www.detelegraaf.nl dus wat de ene keer wel, de andere keer niet ?

Er zit ergens een drukke node tussen, meer is er niet.


J.

Joe de Mannen schreef:Ik heb hier nog geen antwoord gezien van http://www.detelegraaf.nl dus wat de ene keer wel, de andere keer niet ?
Er zit ergens een drukke node tussen, meer is er niet.

zoals je al eerder zei:

Joe de Mannen schreef: Je geraakt toch tot bij de telegraaf op het netwerk en de rest willen ze niet dat je ontdekt, zo simpel is het..

Nema problema!

Joe de Mannen schreef:Dat heeft er niks mee te maken, ik heb net eens dezelfde traceroutes geprobeerd vanop een UK netwerk en krijg hetzelfde resultaat. Security wise antwoorden niet alle systemen op pingcommando's. En dat zal hier wel het probleem zijn. Je geraakt toch tot bij de telegraaf op het netwerk en de rest willen ze niet dat je ontdekt, zo simpel is het.

Er wordt hier nogal snel op de messenger en de pianist geschoten, vind ik.

J.

Dat heeft er wel degelijk iets mee te maken. Ik gebruik zowel Scarlet als Dommel, en merk hetzelfde fenomeen op belgacom nodes aan AMS-IX. En via Telenet: no issue. Lijkt me duidelijk toch?

Astralon schreef:Die resultaten zijn toch zo slecht niet, 15 ms en 32 ms lijken mij redelijke waardes.

Ik zit bij Telenet en haal volgende waardes:
http://www.audi.be: 20 ms
http://www.detelegraaf.nl: 14 ms

Sidon schreef:Tijden vallen nu op dit moment mee maar soms steekt er zo eens eentje tussen van +500 ms.

Dat kan een probleem zijn maar dat is het niet noodzakelijk.
Het heeft allemaal te maken met de prioriteit van de routers.
De prioriteit van een ping ligt gewoon lager dan TCP/UDP data.

Dus om de latency van een router te kennen moet je kijken naar de tijden van de volgende router (hop).
Dus in het voorbeeld van http://www.telegraaf.be heb je op prs-bgc-r3-t2-1.car.belbone.be [80.84.18.154] voor 2 packetjes vrij hoge RTT waarden (105 ms en 93 ms).
Dit wil zeggen dat deze hop respectievelijk 105 ms en 93 ms nodig had om je ping te beantwoorden.

Echter de volgende hop (abovenet.panap.fr [62.35.254.35]) slaagt erin om jouw ping te beantwoorden in 29 ms.
M.a.w. de prs-bgc-r3-t2-1.car.belbone.be was snel genoeg om de data door te sturen naar abovenet.panap.fr maar was trager om de ping te beantwoorden en dat is gewoon omdat de prioriteit van de ping commando's zo laag is.

Je gebruikt dus Telenet... Het voorval doet zich uitsluitend voor bij die ISP's die Belgacom als transit gebruiken tout court. Met alle respect, maar ik merk een enorm verschil tussen voor & na de migratie van Scarlet naar Belgacom transit. Bovendien is het hoogst vervelend dat belgacom al zijn traffiek eerst naar AMS-IX stuurt. Mijn inziens is die router op AMS-IX van belgacom overbelast op piektijden, voor zover ik dat kan zien.

Bedoel je deze? (zie onder, hop 7)
Maar de route van de discussie hierboven gaat niet via AMS-IX.
Die gaat via above.net via brussel-parijs-frankfurt-amsterdam rechtstreeks naar de telegraaf die 10ms langer is dan via ams-ix.

Zoals eerder al geschreven, die route naar De Telegraaf was maar één toevallig voorbeeldje, pin U daar nu niet op vast. Is maar gegeven omdat het gevraagd werd maar in feite ging de vraag dus meer of er nog andere mensen waren die soms van die haperingen opmerkten, meer niet.
(ik mag er toch van uitgaan dat wanneer er bijvoorbeeld de ene keer wel een antwoord wordt gegeven op een ping en de andere keer weer niet, of als ik een tijd zie staan van 4k ms, je mag zeggen dat er iets 'hapert', wat de reden hiervan ook moge zijn)