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.

---

C:\Users\ric>ping -l 40000 74.125.230.132



Pinging 74.125.230.132 with 40000 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.



Ping statistics for 74.125.230.132:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),



Is dit normaal ?

---

@ricy je tracht een paket te versturen dat 40.028 (40000 icmp + 8 icmp header + 20 IP) bytes groot is ... de meeste ADSL-ppp verbindingen ondersteunen paketten die maximaal 1492 bytes groot zijn.



Dus om je 40.000 bytes te versturen gaat je PC/Modem dit opsplitsen in kleinen deetljes die wel binnen de 1492 limiet liggen.



De eindebestemming wordt dan verondersteld om alle afzonderlijk deeltjes weer aaneen te plakken en vervolgens een gepaste actie nemen.



Helaas kunnen mensen met slechte bedoelingen op deze manier een server (zonder bescherming maatregelen) in de problemen brengen.



Daarom beperken de meeste server de groote van deze onvolledig ontvangen paketten in grote en tijd.



Op mijn verbinding ligt die grens op 8755 bytes payload...



PS. Het ligt eigenlijk een beetje complexer want eerst zal je PC die 40.008 bytes groot icmp pakket op splitsen in deeltjes van 1480 bytes icmp (+ 20 bytes ip-header) en vervolgens zal je modem elk deeltje van 1500 bytes opnieuw opsplitsen in één pakket van 1472 (+ 20 bytes IP) en een tweede van 8 (+ 20 bytes IP)



Voor een meer uitgebreidere uitleg: http://penguin.dcs.bbk.ac.uk/academic/networks/network-layer/fragmentation/index.php

---

@Grompy, bedankt voor je uitgebreide uitleg.



'k heb nog eens geprobeerd en pas als ik afdaal tot 33240 (bij herhaaldelijk pingen met zelfde pakket grootte) heb ik geen pakket verlies meer.



C:\Users\ric>ping 74.125.230.132 -l 33240



Pinging 74.125.230.132 with 33240 bytes of data:

Reply from 74.125.230.132: bytes=33240 time=141ms TTL=54

Reply from 74.125.230.132: bytes=33240 time=146ms TTL=54

Reply from 74.125.230.132: bytes=33240 time=153ms TTL=54

Reply from 74.125.230.132: bytes=33240 time=143ms TTL=54



Ping statistics for 74.125.230.132:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 141ms, Maximum = 153ms, Average = 145ms

---

@ https:///people/9a5f0c31ce



Dr Loco:Ik denk niet dat lopen bulderen u probleem sneller gaat oplossen.Iedereen bij Belgacom doet zijn best om U verder te helpen.Als men U antwoord met ik kan U hiervoor niet helpen of een dergelijk antwoord dan zou ik even nadenken over da manier waarop het telefoongesprek verlopen is.Moest ik telefoon krijgen van een klant die op exact dezelfde manier zoals deze post zijn storing uitlegt dan zou ik ook niet veel zin hebben om te helpen.Vriendelijk get's you a long way!Ik begrijp U frustratie maar toch...



------------



Ik zou best uw reactie eens willen zien als het surfen je nagenoeg onmogelijk gemaakt wordt, maar de rekeningen toch mooi blijven komen.

Ik heb dit probleem initieel deftig telefonisch gemeld, dan 10 dagen lang geprobeerd om zoveel mogelijk informatie door te sturen...zonder reactie. En het is net de: zonder reactie de de toon van de posts heeft doen wijzigen.



Onder de theorie dat klagers, zagers en roepers het meest gedaan krijgen, heb ik de initieel vriendelijke toon na 10 dagen zonder verdere uitleg of reactie, noch oplossing voor m'n probleem, gewijzigd. Blijkbaar zitten we in de fase dat er enkel nog op brieven van de ombudsdienst of je advokaat gereageerd wordt, aangezien de andere toon geen meerwaarde gebleken heeft....of misschien toch, want sinds afgelopen weekend zijn de tijden bemoedigender en terwijl dit voor mij blijkbaar geen effect heeft, merk ik toch ZEER duidelijk het verschil.



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 27 ms 20 ms 21 ms 1.85-182-91.adsl-dyn.isp.belgacom.be [91.182.85.1]

3 869 ms * * 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]

4 23 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]

5 25 ms 22 ms 22 ms bru-22-r7-t7-2.car.belbone.be [80.84.21.166]

6 28 ms 27 ms 27 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]

7 27 ms 28 ms 27 ms 94.102.162.208

8 30 ms 27 ms 27 ms 74.125.50.21

9 28 ms 27 ms 41 ms 209.85.252.76

10 31 ms 28 ms 37 ms 209.85.253.88

11 34 ms 34 ms 35 ms 66.249.95.173

12 33 ms 34 ms 34 ms 209.85.251.231

13 42 ms 34 ms 38 ms 209.85.243.85

14 33 ms 33 ms 33 ms google-public-dns-a.google.com [8.8.8.8]



Trace complete.



packet loss naar 61%





@Grompy

volgende en vorige router in het netwerk gaan perfect hoor, enkel de range 91.183.241 geeft issues:



C:\>ping 91.183.247.36 -l 40000



Pinging 91.183.247.36 with 40000 bytes of data:



Reply from 91.183.247.36: bytes=40000 time=165ms TTL=252

Reply from 91.183.247.36: bytes=40000 time=162ms TTL=252

Reply from 91.183.247.36: bytes=40000 time=161ms TTL=252

Reply from 91.183.247.36: bytes=40000 time=170ms TTL=252



Ping statistics for 91.183.247.36:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 161ms, Maximum = 170ms, Average = 164ms



C:\>ping 91.183.241.8 -l 40000



Pinging 91.183.241.8 with 40000 bytes of data:



Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.



Ping statistics for 91.183.241.8:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms





ohja...we zijn ondertussen 24 dagen later!

volle pot betalen...percentje krijgen

---

Lijkt me geen algemeen probleem en verder zeker eens lezen wat Grompy heeft gepost.

---

83.134.114.88



My traceroute [v0.73]

copperhop (0.0.0.0) Tue Jul 5 11:55:17 2011

Keys: Help Display mode Restart statistics Order of fields quit

Packets Pings

Host Loss% Snt Last Avg Best Wrst StDev

1. 194.119.228.2 0.0% 45 1.3 0.7 0.1 1.3 0.5

2. 194.119.228.161 0.0% 45 1.3 0.7 0.2 1.3 0.5

3. 195.207.176.245 0.0% 45 0.8 2.4 0.8 20.6 3.8

4. be2.intlmar2.isp.belgacom.be 0.0% 44 1.2 1.6 0.9 2.4 0.5

5. 37.247-183-91.adsl-static.isp.be 0.0% 44 1.4 5.0 1.0 96.7 14.5

6. 67.241-183-91.adsl-static.isp.be 0.0% 44 4.3 3.8 3.2 4.4 0.5

7. ip-83-134-114-88.dsl.scarlet.be 0.0% 44 20.2 20.1 19.1 21.3 0.5





geen packet loss op die range.













mtr 81.11.221.33



My traceroute [v0.73]

copperhop (0.0.0.0) Tue Jul 5 11:56:23 2011

Keys: Help Display mode Restart statistics Order of fields quit

Packets Pings

Host Loss% Snt Last Avg Best Wrst StDev

1. 194.119.228.2 0.0% 42 0.1 0.7 0.1 1.3 0.5

2. 194.119.228.169 0.0% 42 1.3 0.7 0.1 2.0 0.6

3. 195.207.176.245 0.0% 42 1.9 1.4 0.8 2.0 0.5

4. be1.intlstr2.isp.belgacom.be 0.0% 42 1.8 1.5 0.8 2.0 0.5

5. 33.247-183-91.adsl-static.isp.be 58.5% 42 1.0 3.9 1.0 33.9 7.8

6. 67.241-183-91.adsl-static.isp.be 0.0% 42 4.4 3.7 3.2 4.4 0.5

7. ???



Zoals aangegeven is het reeds beter, maar nog niet opgelost.





Wanneer mag ik eindelijk nog eens een officiële update verwachten van iemand van BGC?















@axs



Bedankt voor je bijdrage, maar met assumpties ben ik helaas niets. Als je de ganse post doorneemt, is dit geen algemeen probleem. Dat toon ik boven ook aan. Probleem bevindt zich in bepaalde range. En zoals reeds aangegeven door anderen, ben ik niet alleen hier de dupe van.

Een test vanop werk toont tevens duidelijk aan dat ieder die langs die range passeert hier problemen van ondervindt. Maar die gegevens mag ik helaas niet posten. Is trouwens niet nodig, de informatie in dit topic is onweerlegbaar.

---

Idd de informatie is onweerlegbaar ... op basis van de informatie uit mtr heb je GEEN probleem!

---

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, ... :)

---

@ Dr Loco:Ik denk niet dat lopen bulderen u probleem sneller gaat oplossen.Iedereen bij Belgacom doet zijn best om U verder te helpen.Als men U antwoord met ik kan U hiervoor niet helpen of een dergelijk antwoord dan zou ik even nadenken over da manier waarop het telefoongesprek verlopen is.Moest ik telefoon krijgen van een klant die op exact dezelfde manier zoals deze post zijn storing uitlegt dan zou ik ook niet veel zin hebben om te helpen.Vriendelijk get's you a long way!Ik begrijp U frustratie maar toch...



@ Strimbello: Het streamen van youtube filmpjes kan soms ook aan de server van youtube liggen.Ik heb zelf een internet intense en sommige filmpjes streamen nu eenmaal rapper dan andere.Net zoals je op ene microsoft website een update kan downloaden aan een aanzienlijk hogere snelheid dan op andere sites...

---

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

---

12 dagen ondertussen



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 20 ms 25 ms 21 ms 1.195-182-91.adsl-dyn.isp.belgacom.be [91.182.19

5.1]

3 3236 ms 3537 ms * 8.241-183-91.adsl-static.isp.belgacom.be [91.183

.241.8]

4 25 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.18

3.247.36]

5 22 ms 22 ms 22 ms bru-22-r7-t3-2.car.belbone.be [80.84.21.106]

6 26 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 27 ms 27 ms 74.125.50.21

9 27 ms 28 ms 28 ms 209.85.255.175

10 28 ms 30 ms 28 ms 209.85.253.94

11 55 ms 34 ms 34 ms 66.249.95.173

12 33 ms 33 ms 33 ms 209.85.251.231

13 38 ms 46 ms 35 ms 209.85.243.73

14 34 ms 33 ms 33 ms google-public-dns-a.google.com [8.8.8.8]



Trace complete.



C:\>



En voor Belgacom nog 4 dagen. Zondag niet opgelost...ikke weg! En iedereen die ik mee weg kan krijgen ook.



Jullie behandelen mensen al veel te lang als domme uilen!

---

we zijn nu 3 dagen na het telefoontje met de technische dienst en ik moet helaas nog steeds geen verbetering van de situatie vaststellen...integendeel the timeout requests worden meer en meer frequent :(



C:\>tracert 74.125.230.132



Tracing route to 74.125.230.132 over a maximum of 30 hops



1 <1 ms <1 ms <1 ms 192.168.1.1

2 21 ms 20 ms 20 ms 1.3-182-91.adsl-dyn.isp.belgacom.be [91.182.3.1]

3 3384 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 22 ms 22 ms 22 ms bru-22-r7-t7-2.car.belbone.be [80.84.21.166]

6 58 ms 209 ms 29 ms 94.102.162.86

7 28 ms 27 ms 28 ms lnd-ix-r3-t3-4.car.belbone.be [80.84.18.0]

8 75 ms 27 ms 29 ms 74.125.50.21

9 28 ms 28 ms 37 ms 209.85.252.76

10 28 ms 28 ms 28 ms 209.85.251.58

11 27 ms 29 ms 27 ms 74.125.230.132



Trace complete.

---

vreemd dat andere adressen in dezelfde range geen problemen geven...

---

Beste DrLoco,



Deze case zal nagekeken worden.

Zodra ik u meer informatie kan geven zal deze hier gepost worden.



Mvg,



Eva van Belgacom

---

misschien dat dit ook handig is?





C:\>ping 91.183.241.8 -l 40000



Pinging 91.183.241.8 with 40000 bytes of data:



Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.

Reply from 91.183.241.8: TTL expired during reassembly.



Ping statistics for 91.183.241.8:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

---

Gaat wel lekker vooruit zo...we zijn weer 10 dagen verder en nog steeds geen deftig antwoord, geen telefoontje, geen verbetering, ..... enige dat uiteraard correct loopt is de rekening, die zit weer mooi in de bus...niet voor de diensten die je hebt kunnen gebruiken, maar voor de diensten die je zou willen gebruiken!





C:\>tracert 74.125.230.132



Tracing route to 74.125.230.132 over a maximum of 30 hops



1 <1 ms <1 ms <1 ms 192.168.1.1

2 24 ms 21 ms 21 ms 1.47-182-91.adsl-dyn.isp.belgacom.be [91.182.47.1]

3 3052 ms * 3180 ms 8.241-183-91.adsl-static.isp.belgacom.be [91.183.241.8]

4 23 ms 22 ms 22 ms 36.247-183-91.adsl-static.isp.belgacom.be [91.183.247.36]

5 22 ms 22 ms 25 ms bru-22-r7-t3-2.car.belbone.be [80.84.21.106]

6 28 ms 27 ms 27 ms lnd-thn-r4-t1-2.car.belbone.be [80.84.18.177]

7 28 ms 27 ms 31 ms 94.102.162.208

8 28 ms 27 ms 27 ms 74.125.50.21

9 28 ms 27 ms 28 ms 209.85.252.76

10 27 ms 28 ms 27 ms 209.85.251.58

11 28 ms 27 ms 27 ms 74.125.230.132



Trace complete.



C:\>

---

Bon ik bel vandaag nog 1 maal en wacht tot morgen.

Als er dan nog geen oplossing of reactie gekomen is, zeg ik op zonder opbrekingsvergoeding wegens het in gebreke blijven door Belgacom EN de laatste faktuur die jullie sture mogen jullie dan ook oproken, aangezien ik niet de dienstverlening gekregen heb waarvoor ik getekend heb.

---

Beste DrLoco,



We zijn u zeker niet vergeten,

Ik tracht zo veel mogelijk druk te zetten om u spoedig een antwoord te kunnen geven.



Alles ligt nu in de handen van ons engineering team.

Gelieve ons nog even respijt te geven.



Mvg,





Eva van Belgacom

---