×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Ziggo en Google lossen verbindingsproblemen met Google-diensten op

Door , 99 reacties, submitter: Matthey

Ziggo heeft in samenwerking met Google de problemen opgelost die tot gevolg hadden dat websites als YouTube, Google en Gmail niet goed bereikbaar waren. Het probleem bleek in de routering van bepaalde ip-adressen tussen Ziggo en Google te zitten.

Op zijn website heeft Ziggo een melding geplaatst dat de storing is opgelost. Ziggo-woordvoerder Gradus Vos meldt desgevraagd aan Tweakers dat het probleem zich voordeed bij een 'beperkt aantal' ip-adressen en dat het te maken had met het border gateway protocol, dat gebruikt wordt om het verkeer te routeren. "Het verkeer kwam wel aan bij de server, maar die was niet in staat om de ip-adressen te resolven", zegt Vos. Daardoor kampten gebruikers met trage verbindingen met Google-diensten.

Volgens Ziggo heeft Google 'bikkelhard meegewerkt' aan de oplossing. Rachid Finge, woordvoerder van Google Nederland, bevestigt dat de zoekgigant heeft geholpen bij het oplossen van de problemen. Sinds het weekend kampten Ziggo-gebruikers met problemen bij het bereiken van Google-diensten. Maandag en dinsdag was het nog onbekend waardoor de problemen werden veroorzaakt.

Update 12.40: Een anonieme tipgever meldt aan Tweakers dat de problemen werden veroorzaakt door een Google-server met het ip 172.217.17.46. Door deze te isoleren zouden de problemen zijn opgelost.

Door Julian Huijbregts

Nieuwsredacteur

12-04-2017 • 12:28

99 Linkedin Google+

Submitter: Matthey

Reacties (99)

Wijzig sortering
Ik zie in de update van dit artikel dat waarschijnlijk server (of loadbalancer) met ip 172.217.17.46 de boosdoener geweest zou kunnen zijn.
Dat kwam me al heel bekend voor (uit een eerdere reactie van mij) :

Err:21 http://dl.google.com/linux/chrome/deb stable InRelease
Could not connect to dl.google.com:80 (172.217.17.46), connection timed out
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/InRelease Could not connect to dl.google.com:80 (172.217.17.46), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.
Zou Ziggo de Class B RFC1918 range (172.16.0.0/12) per ongeluk als een /8 hebben ingevoerd in hun routers? Ik moet zelf ook even twee keer kijken voordat ik doorhad dat dat adres een echt openbaar ip-adres is.
Waarom zou Ziggo die range uberhaupt moeten configureren? Je zou verwachten dat het een standaard instelling is; die ranges zijn al bijna zo oud als IPv4 zelf. RFC1918 lijkt dan wel een hoog nummer, maar de 3 ranges (10.0.0.0/8, 192.168.0.0/16 en 172.16.0.0/12) worden in RFC 1597 al terloops genoemd als bestaande reserveringen.
Zodat zij zelf (van binnenuit) geen verkeer van die ranges naar buiten sturen en (van buitenaf) geen verkeer van die ranges naar binnen accepteren.

Die verwisseling van /12 met /8 lijkt voordehandliggend.
Niet zo heel lastig toch... 172.16.0.0 tot 172.31.255.255. Gezien dit adres duidelijk hier boven is met 217 is het vrij duidelijk dat dit publiek is.
Wat @kdveer vertelt is als je een verkeerd subnet configureert dat het weldegelijk opeens in dat subnet terecht komt.
Top, had er wat last van bij YouTube videos maar dat was makkelijk te verhelpen door wat refreshes. Mooi dat ze samen een snelle oplossing hebben gevonden!
Nou snel? Heb sinds zaterdag last van een trage verbinding naar Google diensten.
Kan ook even duren gezien ze niet makkelijk naar een oplossing konden googlen ;)
comment of the day. dank je _/-\o_
Alleen om die comment al een +1 _/-\o_
Ze konden wel naar een oplossing Bingen :P
Maar met bingen kom je nooit uit op een oplossing ;)
En daarom duurde het 4 dagen :9
Het bleek dan ook wel gecompliceerder te liggen dan ze verwacht hadden - ze hebben namelijk aanspraak moeten maken op Google, dus eenzijdig zou het blijkbaar niet opgelost kunnen worden.
er staat niet specifiek bij waar het fout gelopen is, het kan goed zijn dat de fout bij Ziggo zelf lag en dat ze gewoon niet genoeg technische kennis hadden om het te troubleshooten (wat je wel zou mogen verwachten van een ISP).
Het gaat niet altijd om technische kennis maar ook om inzicht. Daarmee bedoel ik dat hulp van de andere partij vaak tot meer inzicht zorgt.
Het is vaak wel handig als een andere partij ook kan helpen door te zeggen wat zei zien of wat aan hun kant ingesteld staat. Dat is niet gelijk schuld of zelf niet genoeg technische kennis hebben.

Ik heb recent ergens een coreswitch geplaatst die multicast streams van KPN moet routeren. Zijn legio mogelijkheden om dat te regelen maar je bent heel erg afhankelijk van hoe de andere partij zaken heeft ingesteld. Toen ik samen met iemand van KPN hier naar kon kijken waren de zaken snel op elkaar afgestemd. Anders zie je maar de helft en ben je in een soort fog of war aan het werk.
Dit soort problemen zijn niet altijd complex, maar je moet weten waar je moet zoeken.
Daarnaast kwam het onderzoek ook pas laat op gang, het was al sinds het weekend gaande. Ziggo heeft als input alleen wat traceroutes van mensen gevraagd, waarmee het probleem niet direct zichtbaar word.
Hij zegt toch ook niet dat er geen (geldige) rede voor is, enkel dat het niet zo heel vlot was opgelost. 5 dagen is in mijn ogen dan ook niet echt vlot te noemen...
Ik heb hier al weken last van met Youtube. Het stomme is dat het maar eens in de zoveel tijd is. De verbindig tot stand brengen via 4G en dan laten bufferen via Wifi werkt wel vlekkeloos.

Daarom vind ik het ook zo raar aangezien een asynchrone download als Video nu ineens met supertrage snelheid verloopt.
Zo ver ik kon zie was Google er pas dinsdag van op de hoogte en Ziggo maandag. Denk dat er qua monitoring een paar verbeterpunten doorgevoerd moeten worden om dit soort (ruis) over een enkel in/egress point op te vangen.

Voor de tech savy tweakers onder ons die al metingen hadden op zaterdagnacht dat dit mis ging. Een mailtje naar noc@google.com had dit waarschijnlijk al aan het licht gebracht.

[Reactie gewijzigd door rijk0214 op 12 april 2017 20:00]

Aanspraak maken op Google, dat zouden ze wel willen, dan hoefden ze nooit meer voor hun geld te werken. Ik denk dat je bedoelt dat ze Google op het probleem moesten aanspreken, dat is niet onmiddelijk de meest voor de hand liggende formulering maar klopt een stuk beter met wat ze echt gedaan hebben. Ik geef toe, het scheelt maar weinig alleen de betekenis is compleet anders.

[Reactie gewijzigd door mae-t.net op 12 april 2017 20:37]

Ik had alleen gisteren de hele avond last ervan, maar heb ook gehoord dat dit probleem sinds zaterdag/zondag begonnen is.
Ja best wel eigenlijk... je moet ook noet vergeten dat er een behoorlijke tijdsverschil is met NL en USA. Top hoor.
Misschien was je nog niet op de hoogte, maar Google heeft in Nederland ook 'n behoorlijk technisch capabele club zitten. ;)
In de communicatie gaat de meeste tijd zitten. De technische kant is zo opgelost.
Ik doe ook niet alsof ik in die business zit... Jij hebt het nota bene in je profiel staan dat je ervaring met dit soort dingen hebt.

Maar wat logica ons leert (mij althans) is dat er veel getest moet worden om tot een gezamenlijke oplossing te komen... aangezien Ziggo hier is en Google in de usa levert dat toch enige vertraging op.

Nog bedankt voor de -1 meneer met de korte tenen.
Jij weet helemaal niet wat ik doe of hoever mijn expertise gaat. Verder zit ik niet in die business. Mijn functie is lokaal voor een bedrijf, niet voor een ISP. Een hele andere tak van de sport.
Sorry dat ik me ermee bemoei, maar volgens mij heeft Google ook gewoon een kantoor in Nederland, dit staat zelfs in het artikel:
Rachid Finge, woordvoerder van Google Nederland, bevestigt dat de zoekgigant heeft geholpen bij het oplossen van de problemen.
Zelf ben ik van mening dat Ziggo eerder had moeten beginnen met troubleshooten. Dit had de doorlooptijd zeker wel met een aantal dagen verkort. Dat het wat langer duurt om het probleem daadwerkelijk te vinden... Shit happens. Zeker als het het subnet probleem is wat ergens in de comments besproken wordt.

Dat het in eerste instantie afgeschoven wordt snap ik ook nog wel. Het is n specifiek adres bij Google, dus dat daar de schuld gezocht wordt... En daarnaast in de zakelijke markt: uitzoeken kost tijd, en tijd is geld.
Wat dit ook het geval met Play Music, ik had de laatste tijd namelijk geregeld last dat nummers soms laat starten of helemaal niet begonnen met afspelen. Voor de rest had ik totaal geen last met de diensten van Google.
Als 'de laatste tijd' sinds Zaterdag is wel, is 'de laatste tijd' wat langer dan dat, dan niet.
Yep. Bij Play Music was het heel erg merkbaar voor mij. Om de paar nummers duurde het lang voordat het nummer daadwerkelijk wou beginnen. Met YouTube had ik vrijwel geen enkel probleem.
Volgens mij is dit meer Google gerelateerd of secuurder gezegd, ik heb Tweak glasvezel maar ik ervaar dit probleem al veel langer dan de afgelopen week. Sowieso heb ik een knagend gevoel dat er de laatste weken rondom Google iets niet helemaal lekker gaat, ook het uploaden naar Youtube verloopt slecht en soms performen de Google diensten niet zoals je dat bij een Gbit internetverbinding zou verwachten.
Eens. Hier ook al weken minstens. Allerlei Google gerelateerde apps en diensten draaiden gewoon niet lekker. Begon al te denken aan een nieuwe rom voor mijn foon.
Maar... Bij wie lag nou het probleem? Google, Ziggo, of beiden?

Zelf denk ik dat het probleem bij google lag aangezien meerdere providers er last van hadden.


edit: Bericht gepost vr de update. Mocht tipgever juiste info hebben was het dus Google.

Toch jammer dat het meerendeel met het vingertje naar Ziggo wees.

[Reactie gewijzigd door Technomania op 12 april 2017 12:54]

edit: Bericht gepost vr de update. Mocht tipgever juiste info hebben was het dus Google.
Google en Ziggo. Als de storing alleen bij/door Google was, hadden alle ISP's daar last van, niet enkel Ziggo. ;) Ik had er bijvoorbeeld geen last van en niet alle gebruikers op het Ziggo netwerk hadden er last van, zoals ook de reacties laten zien.
Toch jammer dat het meerendeel met het vingertje naar Ziggo wees.
Omdat alleen Ziggo klanten er last van hadden, dan is het logisch dat de oorzaak (eerst) bij Ziggo gezocht wordt.

[Reactie gewijzigd door CH4OS op 12 april 2017 13:03]

Google en Ziggo werken samen om t op te lossen, maar er staat niet in t artikel wie de problemen met BGP nou eigenlijk had. :) Wel raar eigenlijk dat ze dan Google nodig hebben om te analyseren wat er fout gaat met de routering.
Zo raar is dat niet. Ziggo routeert anders naar Google dan XS4ALL of Jonaz of welke ISP dan ook dat doet. :) Daar is het BGP protocol voor, om onderling te delen hoe men routeert. :) Als het dan (in een deel van) een netwerk niet goed gaat, kan dat aan Google of (zoals in dit geval) Ziggo liggen. Uiteindelijk hebben beide partijen eea moeten doen om de routering goed te krijgen.
Nou wat ik hier vreemd aan vind is dat Ziggo er niet zelf achter kan komen wat er niet werkt. Dat terwijl er onder de Tweakers zelf al wat mensen waren die erachter waren welke Google server slecht te benaderen was. Als zij dat al kunnen zien, dan is t leip dat Ziggo daar dagen over doet en hulp van Google moet inschakelen om uit te vogelen wat er niet werkt.
Constateren welke server slecht bereikbaar is is n ding, maar die slechte bereikbaarheid oplossen is vers 2. We weten niet op welk moment Ziggo hulp van Google ingeroepen heeft :)
Omdat alleen Ziggo klanten er last van hadden
Las in de comments van eerdere berichtgevingen dat ook andere providers er last van hadden.
Providers de schuld geven is gewoon het meest makkelijke om te doen, en naar de andere mogelijkheden kijken waar het aan zou kunnen liggen hebben de meeste mensen gewoon geen zin in.

Erg flauw inderdaad dat er vaak genoeg meteen naar een provider wordt gewezen :/

[Reactie gewijzigd door michaell958 op 12 april 2017 14:00]

Door de aard van de storing is dat zelfs logisch; alleen bepaalde Ziggo klanten hadden er last van immers. Anders had iedereen er last van moeten hebben. ;)

[Reactie gewijzigd door CH4OS op 12 april 2017 16:28]

Je was net te vroeg met je reactie. Tweakers heeft een update gegeven.
"Toch jammer dat het merendeel met het vingertje naar Ziggo wees." ... Tja .... Normaal is het andersom, wijst Ziggo naar de klant, want daar zal het probleem wel zitten ...
Het zal wel weer te maken hebben met iets van de migratie van Ziggo naar LGI, iets clueless dat ze bij Ziggo gedaan hebben. Ik geloof niet dat het een actie vanuit Google was.
Zelfde als met de Netflix fuckup begin van het jaar. Snappen het verschil niet tussen peering en transit.
Helaas maar Google zal hier toch echt fout in(als de update klopt).
De update slaat nergens op.

Als ik in het forum de traces bekijk die mensen insturen dan loopt het verkeer naar Google half Europa door qua latency.
Ik heb met Caiway ongeveer 4-6ms latency naar 8.8.8.8 (anycast) en 8-10 hops traceroute.
Hier zie ik op bepaalde tijden wel 40ms wat wil zeggen dat het een rondje Europa doet ofzo.
https://gathering.tweaker...message/50883905#50883905
Hier ook 2 traceroutes onder elkaar, 10ms niks aan de hand, maar 40ms heeft problemen.
https://gathering.tweaker...message/50869529#50869529
Voor mij een indicatie dat ze een gedeelte van het verkeer over een volle link en/of in een ander land hadden lopen.

[Reactie gewijzigd door xmenno op 12 april 2017 13:28]

Wel vreemd dat Tweakers dat niet even grondig heeft gecontroleerd.
Men spreekt in het verhaal ook over BGP, nu is BGP een protocol om je gehele netwerk te adverteren aan een ander netwerk. Niet over iets specifiek binnen Google.
Daarmee sluit je uit dat het probleem hem bij 1 bepaald IP adres zit, want BGP gaat niet over individuele IP adressen maar over hele netwerken (even simpel uitgelegd).

[Reactie gewijzigd door xmenno op 12 april 2017 13:00]

misschien is dat IP een op hol geslagen BGP server? ;)
nu is BGP een protocol om je gehele netwerk te adverteren aan een ander netwerk. Niet over iets specifiek binnen Google.
BGP is een protocol om ip-prefixen te adverteren. Hoe groot die prefixen zijn (hoeveel ip-addressen er in 1 prefix zitten) doet er niet toe. Je kunt dus 65k ip-adressen adverteren als 1 /16. Of als 2 /17s. Of als 256 /24s. Etc. Of 65 duizend /32s.

Dat laatste zal niet gauw gebeuren. Omdat de meeste ISPs en andere netwerken (Autonomous Systems genaamd) hun binnen-komende prefixen filteren. En grof gesproken laten ze niks binnen wat meer specifiek is als een /24.

Er zijn allerlei redenen waarom ASs meerdere prefixen adverteren. Zelfs als die te summarizen zijn. De kracht van BGP zit hem erin dat je heel veel policy kunt configureren. Policy wil zeggen dat mensen bepalen hoe pakketjes over het Internet worden verstuurd. Niet per se de kortste weg.

Dat betekent ook dat er vaak door twee partijen aan een probleem moet worden gewerkt. Omdat partij A meestal geen fouten van B kan herstellen. En B kan vaak niet zien wat er mis gaat bij A.

Bij problemen met BGP is het meestal niet iets technisch wat mis ging (bugs of zo). Meestal gaat het om foute configuraties van policies. Of misverstanden over welke policies er precies gelden tussen twee ASs.

[Reactie gewijzigd door gryz op 12 april 2017 22:21]

Hier met Telenet ging het opvragen van youtube.com heel erg traag, ook het laden van video's. Dat lijkt nu hier ook opgelost.
Klopt. Hier ook veel time-outs op gmail via Telenet sinds een paar dagen.
Ik speel zelf een spel genaamd Path of Exile. Dit lijkt in eerste instantie niet gerelateerd, maar op de forums van het spel en in samenspraak met Reddit zijn we gisteren tot de conclusie gekomen dat in die situatie letterlijk hetzelfde aan de hand was bij backbone providers. Een ip-block die bedoelt was voor de UK werdt in de US advertised waardoor alle connecties via de US werden gerouteerd. Ook hiervan was de veroorzaker BGP. En alleen mensen bij specifieke providers werden er soms langs gerouteerd. Na het fixen van het issue door de amerikaanse backbone provider zayo.com lijken de US spelers nu de issue's te hebben waar Europa last van had.

Een van de mensen die het probleem heeft aangekaart bij de betreffende backbone provider is meegenomen in de CC van de email tussen de backbone providers zayo.com en SoftLayer. Onderstaand een paragraaf uit die email:
Your end customer's reported an issue regarding 37.58.117.146 . That ip block is a UK ip and is being advertised in the US. We have couple things we can do to get this resolve. You do have circuits in UK but no BGP peering. However, static routing would work. Or you can just stop advertising that ip block in the US.
Zo vaak lees ik geen berichten dat er op dit niveau dingen verkeerd gaan. Nu kom ik toevallig binnen 24 uur twee situaties tegen met hetzelfde issue. Alu-hoedje op en relateren maar......... 8)7 volgens mij hebben ze gewoon zitten kwartetten met ip-ranges.

[Reactie gewijzigd door PizZa_CalZone op 12 april 2017 14:31]

En dat lijkt exact het probleem met BGP, het werkt op basis van vertrouwen. Als Rusland (Alu hoedje OP) gaat adverteren dat ze bepaalde reeksen hebben, wordt vrolijk daarheen gerouteerd door "het internet". In die zin kan ook een tikfoutje verstrekkende gevolgen hebben. Bgp-hijacking heet dat zo mooi, hier een leuk artikeltje!

Tijd dat er een goede oplossing komt voor dit soort issues - en die zijn er!

Alu hoedje mag weer af :)
Een hoop ISPs doen heavy filtering van hun binnen komende prefixen. Zo makkelijk is het niet overal om zomaar wat randoms te adverteren. Sommige plaatsen ? Maar echt niet overal.
Dat lijkt me een klus op zich, door het dynamische karakter van het internet verkeer kan het zomaar gebeuren dat je een prefix krijgt die kort ervoor een ander pad volgde, domweg omdat er een routering/kabel stuk is. Je weet hoe groot een BGP tabel kan zijn bij een ISP? Kleine subnetjes zijn ze inderdaad niet dol op, maar ja, die zijn er wel degelijk, alles voorkomen/wegfilteren is een utopie.
Het is heel simpel. Het Internet is niet gratis. Er wordt betaald om traffic door te sturen. Als ik een transit ISP was, met betalende klanten, dan zorgde ik er voor dat ik precies alle traffic door stuur waar voor betaald is. En alle andere traffic die me zou worden aangeboden zou ik simpelweg droppen.

Daar heb je peering-contracten voor. Doodnormale zaak. Filteren is gewoonweg er voor zorgen dat je contracten worden nageleefd.

[Reactie gewijzigd door gryz op 12 april 2017 23:06]

Dan zou er geen BGP nodig zijn, maar zou je af kunnen met statics. En dat is niet het geval, de waarheid zit dan ook in het midden...
Dat is iets te simpel gesteld, en dat weet je zelluf ook wel. :)

BGP zorgt er voor dat je je data over allerlei paden verstuurd en ontvangt. Meer dan 1. En dus is static routing niet goed genoeg.

Maar dat wil niet zeggen dat je *alle* beschikbare paden kunt of mag gebruiken. Met BGP leer je meerdere paden. Maar met je policies gebruik je daar maar een beperkt aantal van.
Mmmm, ik zie het midden :) Fijn Paas gryz
Bedankt. Maar veel Pasen zal ik niet vieren, alleen zondag.

Ik wil m'n nieuwe feature af hebben: behalve "local-address <ip-address>" onder "neighbor" kun je nu ook "local-address <interface-name>" configureren. De BGP neighbor pakt dan het (primary) ip-address van dat interface, en gebruikt het als local-address.

Mag jij raden over welke BGP-implementatie ik het nu heb. :p

Jij ook prettige Paas dagen.
Het is niet perse vreemd dat een IP dat officieel thuishoort in land x, in een ander land wordt geadverteerd. Dus dit is een beetje out of context. :P
De problemen begonnen bij mij vrijdagavond rond een uur of 8. Waarbij ik eerst dachten dat het aan m'n eigen pc lag, zondag lees ik dat meerdere mensen er last van hadden vanaf vrijdag/zaterdag/zondag.

En de verbinding was niet zozeer traag, het duurde gewoon even voordat de website laden, zodra er een verbinding was laden alles vrij snel. Ik kon gewoon het hele weekend 4k materiaal kijken nog. Alleen het tot stand brengen van een verbinding duurde wat langer.

En het had blijkbaar dus niets met dns te maken :)
Leuk statement van Gradus, behalve dat BGP weinig te maken heeft met het resolven van IP adressen.
Nee.

Resolven van IP adressen gebeurt via DNS en wat in die Juniper knowledge base artikel genoemd wordt als resolving betekent eigenlijk alleen het bepalen van de volgende routerings hop.
Misschien is dat ook wel wat er bedoeld wordt, maar zoals het er nu staat klopt niet. Er zijn zat IP adressen die niet te resolven zijn naar een naam maar die wel prima met google kunnen communiceren.

"Resolving" kan vertaald worden als "oplossen", een vrij algemeen term dus. Context is belangrijk, en zoals hier gebruikt niet goed.

[Reactie gewijzigd door wurtel op 13 april 2017 12:42]

Als het je doel is te begrijpen wat ie zegt, blijkt uit de context al dat het een BGP probleem is (dat zegt ie nota bene vlak ervoor).
En ja wat je zelf al zegt, resolven is een algemene term, die blijkens mijn link ook door BGP wordt gebruikt (voor iets anders dan DNS), bij het bepalen van hops (wat je blijkbaar ook al duidelijk is).
Als het je doel is het verkeerd te vinden, kan je daar ongetwijfeld naartoe redeneren. Maar waarom zou je dat doen als je al zo ver bent met de dots connecten. Hij had het mss minder ambigu kunnen formuleren, maar echt fout is het nou ook weer niet.
Hoop dat het opgelost is. Krijg regelmatig zomaar uit het niets een dns fout waardoor mijn Internet dus direct niet meer werkt. Oplossing is gewoon effe mijn pc restarten en het werkt weer.
Ik weet 100% zeker dat het niet aan mijn pc ligt, maar waar het wel precies aan ligt weet ik helaas niet aangezien ik niet zoveel kennis heb van dns. En zonder deze kennis is dit probleem behoorlijk irritant, want ik zou niet weten hoe ik het op moet lossen.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*