Onderwerp: Routing issue Ziggo netwerk

Hi,

ik ondervind momenteel een naar probleem. Vanaf mijn Ziggo verbinding thuis ervaar ik enorme packet loss naar een server in het Rapidswitch (Maidenhead, UK) netwerk. Dit probleem treedt niet op vanaf andere locaties en treedt op bij alle servers in dat netwerk, het ligt dus niet aan de specifieke server. Ik heb middels een traceroute vastgesteld dat het fout gaat bij een hop op een ziggo server/switch, te weten 213.51.148.185.

Hoe kan ik dit nu het beste aan Ziggo melden? Via de klantenservice gaat dit een pijnlijke ervaring worden ben ik bang. Ik kan zo ook geen email adres vinden van het Ziggo NOC.

Alvast bedankt.

Ik wil hem je wel even per PM sturen, maar ze gaan echt niet op één bericht van iemand af. Hier trouwens geen last van packetloss richting Rapidswitch.

Meestal is het makkelijker en sneller om naar een andere provider over te stappen dan iets aan die n00bs uit te leggen helaas

Ik ga via dezelfde router en heb nergens last van. Ping van +- 18ms.

Spyder01 heeft mij inmiddels een email adres van het Ziggo NOC gestuurd, even afwachten op een reactie daarvan.

Spyder01 krijgt overigens ook packetloss naar mijn ip vanaf zijn Ziggo verbinding, het ligt dus niet aan mijn eigen verbinding of iets dergelijks.

Overigens treedt het probleem nu enkel nog op bij mijn ip adres, de gateway van die range bijvoorbeeld is zonder packetloss bereikbaar dus ik begin het vermoeden te krijgen dat het ip op een of andere manier geblacklist is bij Ziggo. Een traceroute vanaf mijn Ziggo verbinding gaat goed, maar een traceroute vanaf de server naar het ziggo netwerk niet.

Even afwachten op een reactie van Ziggo dus, maar waarschijnlijk kan ik in dat geval beter een ander ip adres vragen, ik heb het ip adres pas net in mijn bezit dus ik zou zelf niet de oorzaak zijn bij een eventuele blacklist notatie.

Ooit ook gehad toen ik nog gebruik maakte van Chello. Na elke reset van het modem - en dat moest toen soms wel ettelijke keren per dag - kreeg je dan een nieuw IP-adres en bleek dat IP-adres ook op een RBL te staan.

@dreamhost
Als een IP adres 'geblacklist' staat, krijg je geen partiële packetloss maar algehele packetloss. Je wordt dan gewoon genullroute op de desbetreffende router. Men gaat echt geen ratelimiting doen op een enkel IP van een andere (access)provider en Chello zal zelf ook niet gaan limiten op IP's waarvan ze weet dat deze dynamisch zijn.

Oorspronkelijk geplaatst door Dufu

het fout gaat bij een hop op een ziggo server/switch, te weten 213.51.148.185

Wat bedoel je hiermee? Waarmee heb je naar welk IP getraced en wat constateer je? Dat een router niet reageert op al je ICMP requests wil niet zeggen dat hij niet goed werkt. Voorts is switching L2, een switch zul je dus nooit zien in een normale trace.

Het zou dus heel goed zo kunnen zijn dat de loss optreedt in een link bij een ander netwerk tussen Ziggo en Rapidswitch. Uit je posts kan ik dat i.i.g. niet opmaken.

Oorspronkelijk geplaatst door Dufu

Overigens treedt het probleem nu enkel nog op bij mijn ip adres, de gateway van die range bijvoorbeeld is zonder packetloss bereikbaar dus ik begin het vermoeden te krijgen dat het ip op een of andere manier geblacklist is bij Ziggo. Een traceroute vanaf mijn Ziggo verbinding gaat goed, maar een traceroute vanaf de server naar het ziggo netwerk niet.

Asynchronous routing komt heel vaak voor. Zowel Ziggo als Mainswitch hebben beiden hun eigen 'localpreferences'. Dat betekent dat beide netwerken hun packets via een andere weg naar de ontvanger sturen. De route van Ziggo naar Mainswitch kan dus anders zijn dan de weg terug. Dat verklaart waarschijnlijk ook waarom je loss hebt met de ene trace en geen loss met de andere trace en het tacklet mooi dat rare blacklist verhaal . Vergelijk beide traces eens goed.

@Cybafish

Zie de traceroute vanaf mijn server naar mijn Ziggo ip:

Code:

 1  gateway.dns4vps.com (109.169.51.1)  0.786 ms  0.503 ms  0.520 ms
 2  87.117.212.193  1.959 ms  0.742 ms  0.562 ms
 3  87.117.211.61  2.501 ms  1.630 ms  1.740 ms
 4  ge-4-13_ge-4-14.cat1.sov.lon.as29131.net (87.117.211.10)  1.876 ms  1.778 ms  1.829 ms
 5  xe-0-1-0-201.lon20.ip4.tinet.net (213.200.79.209)  1.144 ms  1.215 ms  1.193 ms
 6  xe-11-1-0.ams20.ip4.tinet.net (89.149.186.202)  22.450 ms  7.210 ms  7.331 ms
 7  casema-gw.ip4.tinet.net (77.67.64.66)  7.374 ms  7.698 ms  7.454 ms
 8  ht-rc0001-cr101-ae0-0.core.as9143.net (213.51.158.151)  10.369 ms  10.676 ms  10.634 ms
 9  * * *
10  213.51.148.185  16.360 ms  16.544 ms  16.448 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Destination not reached

Doordat hierboven de trace vanaf hop 10 (ziggo switch) geen zinnige output meer gaf kwam ik tot de conclusie dat het daar fout ging. Zou dat niet het geval zijn?

Traceroute vanuit mijn Ziggo ip naar de server:

Code:

 1  unknown (192.168.1.1)  5.739 ms  5.348 ms  5.594 ms
 2  10.244.176.1 (10.244.176.1)  16.416 ms  11.467 ms  13.465 ms
 3  csw1-vlan201.landg1.lb.home.nl (213.51.148.130)  11.840 ms  13.527 ms  11.121 ms
 4  213.51.157.199 (213.51.157.199)  63.315 ms  31.541 ms  13.137 ms
 5  asd-lc0006-cr101-ae4-0.core.as9143.net (213.51.158.150)  29.099 ms  64.635 ms  44.557 ms
 6  te2-1.ccr01.ams05.atlas.cogentco.com (149.6.129.13)  18.033 ms  24.166 ms  21.813 ms
 7  * tiscali.ams05.atlas.cogentco.com (130.117.14.246)  15.626 ms
    77.67.82.225 (77.67.82.225)  17.237 ms
 8  * xe-9-2-0.lon25.ip4.tinet.net (89.149.185.69)  23.163 ms  25.416 ms
 9  * rapidswitch-gw1.ip4.tinet.net (213.200.79.210)  27.449 ms  25.636 ms
10  * * *
11  * * *
12  mijn.hostname (109.169.51.x)  29.944 ms  25.796 ms  27.000 ms

Dat mijn server ip geblacklist zou zijn was slechts een vermoeden, dat het door asynchronous routing komt lijkt inderdaad waarschijnlijker.

Edit: overigens was dat blacklist vermoeden ook gebaseerd op het feit dat een ping naar een ander ip in dezelfde range wel goed gaat vanaf mijn thuis verbinding. Op just-ping.com treedt er vanaf Groningen (gw.watchmouse.com, zit zo te zien ook in het Ziggo netwerk, of gaat daar in ieder geval overheen) op andere ip adressen in mijn range wél ook packet loss op?

Die sterretjes in je trace zeggen niets meer dan "er is niet binnen de toegestane tijd op ons (vaak) ICMP pakketje gereageerd". Dat kan bijvoorbeeld ook het geval zijn als de router in kwestie geen ICMP terugstuurt, hetgeen soms uit veiligheidsoverwegingen wordt gedaan. Trace eens met optie -T (unix). Je tracet dan over TCP, in plaats van ICMP (of UDP).

Voor wat betreft dit specifieke geval; het lijkt erop dat zowel Ziggo (casema) als Rapidswitch transit afnemen van Tinet. Rapidswitch heeft geen directe peering met Ziggo en stuurt pakketjes via Tinet naar Ziggo. Er zit dus maar één netwerk tussen beiden. Rapidswitch -> Tinet -> Ziggo.

De route van Ziggo naar Rapidswitch is een ander verhaal. Hoewel Ziggo beschikt over een lijn van Tinet en dat waarschijnlijk de kortste route is, beschikt Ziggo ook over transit van Cogent. Cogent is lekker goedkoop, dus heeft de administrator van Ziggo op de router ingesteld dat hij pakketjes liever via Cogent laat lopen als dat mogelijk is. De route van Ziggo naar Rapidswitch wordt dan ook: Ziggo -> Cogent -> Tinet -> Rapidswitch.

Vermoedelijk zit het probleem dus (zoals wel vaker) bij Cogent. Je kunt dus wel bij het NOC van Casema aankloppen met het verzoek om speciaal voor jou een duurdere transit in te zetten, maar het mag in de krant als dat verzoek ook wordt ingewilligd

Consumenten staren zich altijd blind op de netwerksnelheid, maar de kwaliteit van de uplinks is eigenlijk van veel groter belang. Binnen Nederland zit dat voor Ziggo wel goed, ze peeren namelijk bijna met iedereen. Gaat e.e.a. echter over transit, dan heb je een grote kans dat de spreekwoordelijke aap uit de mouw komt.

Bedankt voor je uitgebreide reactie Cybafish.

Bovenstaande trace is een tcp trace, was ik vergeten te vermelden.

Maar een ping naar een ander ip in dezelfde range gaat dus wel goed. Ik ben niet zo'n netwerk foo, maar ik neem aan dat routering op subnet oid gebeurd, dus gaat dat verhaal nog wel op dan?

Zie http://www.db.ripe.net/whois/?form_t..._search=Search

Routing gebeurt inderdaad op subnetniveau. Voor zover ik kan zien wordt er alleen een /18 announced door Rapidswitch (109.169.0.0/18), waar het door jou opgegeven IP onder valt. Als jij het hebt over een ander IP 'binnen dezelfde range', dan heb je het denk ik over 109.169.51.0-255 (/24), maar die valt dus binnen het veel grotere geheel (de /18). Het verhaal gaat dus ook op voor het andere IP.

Het is raar dat je stelt dat het nu alleen nog maar het geval is bij dat éne IP adres, waar het eerder nog gold voor de hele range. Dat kan eigenlijk niet, tenzij er een firewall in het spel is die ratelimit op jouw specifieke IP (anders had je uberhaupt geen verbinding, nu heb je slechts loss). De grap daarvan is dat het dan in beide gevallen problemen zou moeten geven (dus zowel bij een ping van server -> jou en van jou -> server).

Is de loss sporadisch/continue, variabel of constant? Hoeveel loss heb je? Hoe meet je?

Met een ander ip in dezelfde range bedoel ik inderdaad een ip in de 109.169.51.0-255. Vanaf mijn thuis Ziggo verbinding krijg ik enkel op mijn eigen ip adres packet loss, bij een ping komt er geen response. Websites en mail zijn wel bereikbaar, maar mail geeft regelmatig een timeout. Ook HTTPS verkeer werkt erg traag. Vanaf andere locaties buiten het Ziggo netwerk werkt dit allemaal probleemloos.

De loss die ping weergeeft is continue en constant 100%.

Ik heb dit nog nooit meegemaakt en ik weet nu ook echt niet meer waar ik het probleem moet zoeken.

Wat het nog vreemder maakt, is dat vanaf gn.watchmouse.com (via just-ping.com website) niet alleen mijn eigen ip, maar ook bijvoorbeeld de gateway (.1) 100% packetloss vertoond.

Oorspronkelijk geplaatst door Dufu

@Cybafish

Zie de traceroute vanaf mijn server naar mijn Ziggo ip:

Code:

 1  gateway.dns4vps.com (109.169.51.1)  0.786 ms  0.503 ms  0.520 ms
 2  87.117.212.193  1.959 ms  0.742 ms  0.562 ms
 3  87.117.211.61  2.501 ms  1.630 ms  1.740 ms
 4  ge-4-13_ge-4-14.cat1.sov.lon.as29131.net (87.117.211.10)  1.876 ms  1.778 ms  1.829 ms
 5  xe-0-1-0-201.lon20.ip4.tinet.net (213.200.79.209)  1.144 ms  1.215 ms  1.193 ms
 6  xe-11-1-0.ams20.ip4.tinet.net (89.149.186.202)  22.450 ms  7.210 ms  7.331 ms
 7  casema-gw.ip4.tinet.net (77.67.64.66)  7.374 ms  7.698 ms  7.454 ms
 8  ht-rc0001-cr101-ae0-0.core.as9143.net (213.51.158.151)  10.369 ms  10.676 ms  10.634 ms
 9  * * *
10  213.51.148.185  16.360 ms  16.544 ms  16.448 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Destination not reached

Doordat hierboven de trace vanaf hop 10 (ziggo switch) geen zinnige output meer gaf kwam ik tot de conclusie dat het daar fout ging. Zou dat niet het geval zijn?

Traceroute vanuit mijn Ziggo ip naar de server:

Code:

 1  unknown (192.168.1.1)  5.739 ms  5.348 ms  5.594 ms
 2  10.244.176.1 (10.244.176.1)  16.416 ms  11.467 ms  13.465 ms
 3  csw1-vlan201.landg1.lb.home.nl (213.51.148.130)  11.840 ms  13.527 ms  11.121 ms
 4  213.51.157.199 (213.51.157.199)  63.315 ms  31.541 ms  13.137 ms
 5  asd-lc0006-cr101-ae4-0.core.as9143.net (213.51.158.150)  29.099 ms  64.635 ms  44.557 ms
 6  te2-1.ccr01.ams05.atlas.cogentco.com (149.6.129.13)  18.033 ms  24.166 ms  21.813 ms
 7  * tiscali.ams05.atlas.cogentco.com (130.117.14.246)  15.626 ms
    77.67.82.225 (77.67.82.225)  17.237 ms
 8  * xe-9-2-0.lon25.ip4.tinet.net (89.149.185.69)  23.163 ms  25.416 ms
 9  * rapidswitch-gw1.ip4.tinet.net (213.200.79.210)  27.449 ms  25.636 ms
10  * * *
11  * * *
12  mijn.hostname (109.169.51.x)  29.944 ms  25.796 ms  27.000 ms

Dat mijn server ip geblacklist zou zijn was slechts een vermoeden, dat het door asynchronous routing komt lijkt inderdaad waarschijnlijker.

Edit: overigens was dat blacklist vermoeden ook gebaseerd op het feit dat een ping naar een ander ip in dezelfde range wel goed gaat vanaf mijn thuis verbinding. Op just-ping.com treedt er vanaf Groningen (gw.watchmouse.com, zit zo te zien ook in het Ziggo netwerk, of gaat daar in ieder geval overheen) op andere ip adressen in mijn range wél ook packet loss op?

Nitpickje : asymmetrische routering (niet asynchroon).
Als ik naar deze traceroutes kijk denk ik dat het alleen je kabelmodem is wat geen antwoord meer geeft, of mogelijk je head end.
Ben je thuis uberhaupt bereikbaar voor inkomende connecties ?

Kijk maar naar de trace vanaf je thuismodem : de eerste ziggo hop is (misschien) 10.244.176.1 , en daarna 213.51.148.130 .

De trace vanaf je server heeft als laatste zichtbare hop 213.51.148.185 .

Nu heeft een router gewoonlijk op elk interface een eigen IP adres.
En verkeer wat de router zelf initieert krijgt als source adres het IP adres van het uitgaande interface.
Bij traceroute initieert de router verkeer (namelijk een ICMP TTL expired packet), en met als source adres dus het uitgaande interface van de router (in de richting van de bron die de traceroute deed).

Ik denk dus dat 213.51.148.130 en 213.51.148.185 IP adressen op dezelfde router zijn, de ene aan de kant van de endusers, de andere aan de kant van de netwerk core en internet.

Verder hoort een netwerk private adressen (zoals 10.x.x.x) als source adres niet het Internet op te laten komen, of niet binnen te laten komen.

Het zou dus best kunnen dat de hop met 10.x die je in je trace vanaf huis ziet, in de trace vanaf de server niet zichtbaar is omdat het antwoord hetzij door Ziggo niet naar buiten (internet, blijkbaar wel nog naar endusers) gestuurd wordt, hetzij gedropt door een tussenliggend netwerk. [Allebei terecht].

Als je thuismodem/thuisserver dan ook geen antwoord geeft klopt het dat je na de laatste hop met routeerbaar adres geen antwoord meer ziet.

Om dat te testen moet je een service (bv http) op je thuisbak draaien en bereikbaar hebben, en zou je met tcptraceroute de laatste hop (je server) zichtbaar moeten hebben.
Ik ken de ziggo dienst verder niet, maar als het modem standaard dicht staat voor services en traceroute is het effect dat je traceroute niet aankomt hetzelfde.

Problemen voor precies 1 IP in een reeks zullen bijna altijd op of vlakbij dat IP zitten; Dus als er inderdaad een probleem met alleen jouw server in het hele subnet zit, zal dat eerder hetzij in die server , hetzij bij de colo provider zitten.

@visser, inderdaad asymmetric routing, schoonheidsfoutje

Wat TS er niet bij heeft vermeld, en voor zover ik kan zien wel het geval is, is dat het hier gaat om een VPS. Het lijkt erop dat 109.169.51.2 de VPS 'host' is en dat een aantal andere IP's in die range VPS'jes zijn.

De VPS host maakt voor iedere VPS een virtuele interface aan. Vervolgens bridget hij het verkeer van de fysieke netwerk interface naar de virtuele interface (en andersom). Dit zie je niet in de trace, maar het kan wel zo zijn dat het host systeem bepaalde zaken filtert -- eventueel zelfs voor jouw IP. Zo gebeurt er stiekem iets op L3, terwijl bridging eigenlijk L2 is.

Dat je op verschillende services verschillende problemen hebt, kan goed kloppen. Zo is een 'HTTP connectie' behoorlijk tolerant -- als een verbinding wegvalt stuurt de browser net zo makkelijk een nieuw verzoek. Vervelender wordt het als er een persistente connectie opgezet moet worden, zoals dat bijvoorbeeld voor mail het geval is. Voor HTTPS betekent een drop dat er weer een hele nieuwe SSL sessie opgezet moet worden. Dat is meer werk, dus bij een lossy connection zal de impact op SSL verbindingen ook groter zijn. Daarnaast horen bij verschillende services ook vaak verschillende soorten protocollen (e.g. UDP/TCP). Als één van beiden (deels) geblokkeerd wordt, kun je ook rariteiten verwachten.

Tenslotte, pingen of tracen naar een gateway adres vanaf een extern netwerk is nooit een goed idee. Een extern netwerk heeft eigenlijk niets te zoeken bij een gateway (=intern).

@visser,

Met een service beschikbaar op mijn thuis ip en een tcptraceroute daarnaar toe krijg ik mijn thuis ip wel te zien in de trace inderdaad. De trace ziet er dan zo uit:

Code:

Tracing the path to 84.25.114.x on TCP port x (x), 30 hops max
 1  range-4.gateway.pcsmarthosting.co.uk (109.169.51.1)  0.585 ms  0.489 ms  0.570 ms
 2  87.117.212.193  2.251 ms  0.390 ms  0.820 ms
 3  87.117.211.61  1.928 ms  1.909 ms  1.842 ms
 4  ge-4-13_ge-4-14.cat1.sov.lon.as29131.net (87.117.211.10)  194.533 ms  189.859 ms  445.646 ms
 5  xe-0-1-0-201.lon20.ip4.tinet.net (213.200.79.209)  1.180 ms  1.128 ms  1.380 ms
 6  xe-9-3-0.ams20.ip4.tinet.net (89.149.187.41)  8.576 ms  8.463 ms  8.715 ms
 7  casema-gw.ip4.tinet.net (77.67.64.66)  8.309 ms  8.198 ms  8.309 ms
 8  ht-rc0001-cr101-ae0-0.core.as9143.net (213.51.158.151)  11.254 ms  11.213 ms  11.240 ms
 9  * * *
10  213.51.148.185  16.873 ms  16.924 ms  17.153 ms
11  x.dynamic.ziggo.nl (84.25.114.x) [open]  18.704 ms  20.987 ms  21.625 ms

@Cybafish

Het klopt inderdaad dat het om een VPS gaat. Zou het dan toch kunnen dat er op de node een firewall dwarsligt bijvoorbeeld?