issues met 8.241-183-91.adsl-static.isp.belgacom.be

Hoi allemaal, hierbij een update van de situatie met de tragere internet-lijn.

Scarlet legde de schuld bij Belgacom, en belgacom wilde vervolgens "de lijn" checken. Concequentie is dat er den een Belgacom technieker moet langstkomen om deze te meten en te analyseren. (Iest waar ik geen zin in had maar ok... verlofdagen genoeg zeker? -ehem-)Na twee mislukte afspraken en het opdagen in de na-, ipv in de voormiddag is deze technieker vandaag langst gekomen.
De lijn zelf op physical layer is in orde, zelfs zeer goed.Toch zag deze Belgacom medewerker zelf met zijn laptop dat er delays waren. De inmiddels beroemde traceroute naar een dns server leverde een +3000ms delay op. Surfen ging traag, pings gingen af en toe verloren. Packet loss verder op het netwerk.

De conclusie is andermaal dat er wat schort op "het netwerk". Hij liet wijselijk in het midden of dat nu het Scarlet of BGC gedeelte was. Maar dat kan mij als klant niet echt schelen uiteraard. (hint: derde hop met de huge delay is een belgacom router).
Los van al deze zever zit ik nog steeds met een abonnement van Scarlet waar niet over te gamen valt, waar loss op zit en waar er blijkbaar echt iets schort bij de verbinding tussen Scarlet en Belgacom ofzo. Ik ben steeds bereid om mee te werken of te testen hoor, zolang er maar iemand zich eens mee bezig houdt op een constructieve manier.

Ik vind het vooral gigantisch storend dat ik via Scarlet, doorheen hun helpdesk (of impressie daarvan) met Belgacom moet praten. Dit veroorzaakt elke keer een enorme delay en miscommunicatie, maar misschien staat dat symbool voor hetgeen er tussen hun twee netwerken gebeurd op technisch vlak. Wie weet...

PS: Dr. Loco, indien ge een praatgroep hieromtrend wil oprichten, ... :)

Even ter info...er is geen Scarlet netwerk.
Scarlet heeft zijn netwerk, opgelegd door het BIPT, moeten verkopen. Scarlet maakt dus 100% gebruik van het Belgacom netwerk. Van intropunt bij de klant tot egres router naar een peering provider.
Wat Scarlet doet, is exact hetzelfde als wat EDPnet of elke andere DSL retail provider doet. Ze huren lijnen bij Belgacom, dat tot op heden nog steeds het meest stabiele en performante netwerk in België is.

Zoals met alle technologie, gaat er altijd wel eens iets mis. Wat me hier wel enorm stoort dat de waarheid rond wat er misgaat telkens de doofpot ingaat, en er nooit deftig met de eindklant gecommuniceerd wordt.Wat alle non-believers ook mogen beweren rond de reeds geposte info, het resultaat is overduidelijk visueel zichtbaar wanneer een internet pagina geopend wordt, en werd dan nu dus door BGC techniekers zelf bevestigd....misschien dat er nu dan eindelijk voor een oplossing gezorgd kan worden, of allerminst voor een duidelijke communicatie.

Helemaal correct zou het dan nog zijn, als ik einde maand enkel aangerekend wordt voor wat ik heb kunnen gebruiken (en dat was niet bijster veel), maar dat zal, vrees ik, helaas een brug te ver zijn.

Hoi iedereen, nogmaals een update over dit issue.

Tot nu toe: problemen met packet loss, algehele lijn kwaliteit, ... scarlet kon dit bevestigen, belgacom technieker is langst geweest en bevestigde dit ook (circuitnummer gekend). Dit was vorige week (na een maand klagen).

Er is sindsdien niets gebeurd. Wat me vooral opvalt is dat zowel Scarlet als Belgacom geen opvloging schijnen te doen van zulke issues.

Wanneer je belt moet je telkens van nul heel je probleem uitleggen... een ticketnummer krijg je niet echt.

Nu de problemen ook door een belgacom technieker zijn gemeld, zou ik verwacht hebben dat er enige communicatie naar mij toe zou zijn over het verder verloop van dit issue. Scarlet is anders zeer snel met mensen te sms'en en te mailen, maar dan opeens wordt het heel stil aan de andere kant van de lijn.

Bellen naar hun helpdesk heb ik inmiddels opgegeven (in totaal nu 6u mee kwijgespeeld, en uiteindelijk kom je dan bij Janssens Field Services terecht die je dan opnieuw in de wachtrij van Scarlet helpdesk in Zaventem duwen en waar ge naar het walgelijkste wachtmuziekje ever mag luisteren tot ge er zot van wordt.

Ik ben benieuwd of er nu, zonder inbreng van mijn part, nog iemand deze case ter harte gaat nemen... Ik betaal inmiddels braaf mijn rekening.

Hieronder nogmaals een pathping van vandaag 11 juli:

1 0ms 1/ 100 = 1% 1/ 100 = 1% home.xxxxxx [192.168.1.1]

2 18ms 0/ 100 = 0% 0/ 100 = 0% ip-83-134-115-1.dsl.scarlet.be [83.134.115.1]

3 22ms 2/ 100 = 2% 2/ 100 = 2% 66.241-183-91.adsl-static.isp.belgacom.be [91.183.241.66]

| 4 23ms 0/ 100 = 0% 0/ 100 = 0% 32.247-183-91.adsl-static.isp.belgacom.be [91.183.247.32]

| 5 28ms 0/ 100 = 0% 0/ 100 = 0% v4.icoremar1.isp.belgacom.be [194.78.0.133]

| 6 --- 100/ 100 =100% 100/ 100 =100% gig4-3.iptr.vil-ar02.mpl.scarlet.be [195.207.176.246]

| 7 22ms 0/ 100 = 0% 0/ 100 = 0% dnsl.scarlet.be [193.74.208.135]


De trace is voltooid.

Ze zijn er alleszinds mee bezig...morgen update hierover...en de verbetering is duidelijk merkbaar als ik een internetpagina open, of iets stream....toevallig gaat het ook gepaard met veel minder packetloss en verbeterde trace...duidelijk niets met elkaar te maken

C:\>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 22 ms 20 ms 20 ms 1.224-182-91.adsl-dyn.isp.belgacom.be [91.182.224.1]
3 330 ms 204 ms 395 ms 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]
4 23 ms 23 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]
5 22 ms 25 ms 26 ms bru-22-r7-t4-3.car.belbone.be [80.84.20.98]
6 34 ms 22 ms 22 ms 94.102.162.86
7 27 ms 27 ms 27 ms lnd-ix-r3-t3-4.car.belbone.be [80.84.18.0]
8 27 ms 31 ms 27 ms 74.125.50.21
9 27 ms 34 ms 28 ms 209.85.255.175
10 30 ms 28 ms 31 ms 209.85.253.94
11 34 ms 34 ms 34 ms 66.249.95.173
12 33 ms 33 ms 38 ms 209.85.251.231
13 35 ms 34 ms 34 ms 209.85.243.73
14 34 ms 34 ms 34 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

C:\>

Dit is het resultaat dat ik krijg:

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.1.1
2 20 ms 19 ms 19 ms 1.30-130-109.adsl-dyn.isp.belgacom.be [109.130.3
0.1]
3 * * 28 ms 160.241-183-91.adsl-static.isp.belgacom.be [91.1
83.241.160]
4 20 ms 20 ms 20 ms 26.247-183-91.adsl-static.isp.belgacom.be [91.18
3.247.26]
5 20 ms 20 ms 20 ms bru-22-r7-t3-3.car.belbone.be [80.84.21.110]
6 30 ms 30 ms 30 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]
7 28 ms 28 ms 27 ms 94.102.162.208
8 28 ms 27 ms 27 ms 74.125.50.21
9 28 ms 28 ms 29 ms 209.85.255.175
10 28 ms 28 ms 28 ms 209.85.253.94
11 34 ms 34 ms 34 ms 72.14.232.134
12 35 ms 34 ms 34 ms 209.85.252.83
13 43 ms 34 ms 43 ms 209.85.243.85
14 35 ms 34 ms 34 ms google-public-dns-a.google.com [8.8.8.8]

bij mij staan bij regel 3 twee "*", wat is hiervan de reden ?

Jeps, vanmorregend hadden ze blijkbaar het op non-response gezet op icmp requests.

En intussen is het bekende probleem weer terug.... gevolgen: traag surfen (supersnel internet anyone?) en packet loss...

1 13 ms <1 ms 10 ms home
2 20 ms 17 ms 29 ms ip-83-134-114-1.dsl.scarlet.be [83.134.114.1]
3 2596 ms 2860 ms 2331 ms 66.241-183-91.adsl-static.isp.belgacom.be [91.183.241.66]
4 20 ms 30 ms 20 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]
5 19 ms 33 ms 30 ms bru-22-r7-t3-3.car.belbone.be [80.84.21.110]
6 25 ms 25 ms 24 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]
7 35 ms 29 ms 31 ms 94.102.162.208
8 24 ms 26 ms 29 ms 74.125.50.21
9 25 ms 25 ms 25 ms 209.85.255.175
10 25 ms 25 ms 26 ms 209.85.253.90
11 31 ms 33 ms 31 ms 66.249.95.173
12 73 ms 30 ms 31 ms 209.85.252.83
13 33 ms 49 ms 57 ms 209.85.243.85
14 40 ms 31 ms 48 ms google-public-dns-a.google.com [8.8.8.8]
De trace is voltooid.

Maar dan een trace naar de belgacom DNS server (ik zit bij scarlet)

C:\>tracert 81.240.251.100
Bezig met het traceren van de route naar 100.251-240-81.adsl-static.isp.belgacom.be [81.240.251.100]via maximaal 30 hops:
1 1 ms 1 ms 1 ms home
2 38 ms 18 ms 18 ms 10.180.0.1
3 20 ms 20 ms 20 ms 172.17.240.149
4 20 ms 20 ms 22 ms 10.48.12.81
5 21 ms 34 ms 20 ms 100.251-240-81.adsl-static.isp.belgacom.be [81.240.251.100]

De trace is voltooid.

Hm, en men blijft beweren dat er geen twee netwerken zijn?

Oh ja: kan er iemand van Scargacom eens support geven hierover?

Er is sinds begin van het perikel al verbetering ...

C:\>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 25 ms 27 ms 21 ms 1.162-182-91.adsl-dyn.isp.belgacom.be [91.182.162.1]
3 718 ms 600 ms * 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]
4 22 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]
5 23 ms 22 ms 22 ms bru-22-r7-t3-2.car.belbone.be [80.84.21.106]
6 27 ms 27 ms 27 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]
7 27 ms 27 ms 27 ms 94.102.162.208
8 28 ms 27 ms 31 ms 74.125.50.21
9 27 ms 27 ms 29 ms 209.85.252.76
10 27 ms 28 ms 27 ms 209.85.253.88
11 33 ms 34 ms 33 ms 66.249.95.173
12 33 ms 33 ms 33 ms 209.85.252.83
13 40 ms 38 ms 33 ms 209.85.243.73
14 33 ms 41 ms 34 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

En packet loss is afgenomen. Het probleem is echter nog niet opgelost en veroorzaakt regelmatig nog steeds issue met laden van pagina's.

Ondertussen ook de bbox van iemand waar het wel werkt zoals het hoort eens aan m'n lijn gehangen om uit te sluiten dat hier het probleem zou liggen. Bij deze is deze optie dus ook uitgesloten, want die vertoonde exact dezelfde resultaten als m'n eigen bbox.

Aangezien men hier in alle talen zwijgt , en blijkbaar weigert updates of een antwoord/verklaring te geven rond dit issue, heb ik eens gaan sprokkelen in enkele contacten uit een vorig leven (en funktie). Deze bevestigden me alleszinds wel dat er aan gewerkt werd, wat ook zoveel betekent dat er inderdaad een issue is. Helaas, en ook wel begrijpelijk, konden ze me dit niet schriftelijk bevestigen.

"Aangezien men hier in alle talen zwijgt , en blijkbaar weigert updates of een antwoord/verklaring te geven rond dit issue, heb ik eens gaan sprokkelen in enkele contacten uit een vorig leven (en funktie). Deze bevestigden me alleszinds wel dat er aan gewerkt werd, wat ook zoveel betekent dat er inderdaad een issue is. Helaas, en ook wel begrijpelijk, konden ze me dit niet schriftelijk bevestigen."

DrLoco wat zou de toegevoegde waarde zijn van hun uitleg, je staat helemaal niet open voor de reeds gegeven antwoorden en/of verklaringen in deze thread. Op basis van de output van de verschillende MTR/traceroute/tracert kan ik enkel besluiten dat er geen impact is voor data transfers komende van het internet doorheen de router in hop 3.

Ja de router op hop 3 heeft hoge heen-en-terug tijden, voor de reden waarom zie één van mijn eerdere reacties.

De meeste mensen die in deze thread 'problemen' rapporteren met de derde hop gaan ervan uit dat doordat die router 'traag' reageert en packetloss heeft dit een invloed geeft op hun surf/internet ervaring. INDIEN dit het geval was hoe verklaar je dan dan de volgende routers naar de bestemming toe 'plots' die vertragingen en verlies van paketten NIET meer hebben? Of denk je dat de paketten een andere weg nemen om van hop 2 naar hop 4 te gaan die niet langs hop 3 gaat ?

Persoonlijk ben ik ervan overtuigd dat mensen die klagen op basis van de hierboven geposte trace-programma's niet echt weten/begrijpen wat de output van deze programma's juist betekent ?

Ik daag de mensen uit die hier reeds verschillende outputs hebben gepost van een 'mtr' om TIJDENS de uitvoering ervan (via een tweede ssh/telnet sessie) een ping (icmp) test uit te voeren naar het adres die 'problemen' geeft.

Grompy

PS. Ik twijfel ZEEEEER sterk aan die bevestiging van je oud colega's. Mijn vermoeden over het 'schijnbaar' verbeteren van de situatie lijkt me meer te maken met de vakantie periode.

@strimbello Ik vermoed dat je verkeerd bent ingelicht de DNS servers voor Skynet zijn 195.238.2.21 en 195.238.2.22.

Het adres 81.240.251.100 lijkt op basis van open poorten meer iets van een VOIP infrastructuur te hebben.

Grompy