CloudFlare klaagt over Telia na omvangrijke Europese internetstoring

Internetbedrijf CloudFlare heeft details gepubliceerd over de omvangrijke internetproblemen die Europeanen maandag hebben ervaren. Het content delivery network legt de schuld bij Telia en noemt de storing onacceptabel. De oorzaak zou een menselijke fout zijn geweest.

Maandag hadden veel Europese internetgebruikers verbindingsproblemen met meerdere diensten, zoals Slack, WhatsApp en Reddit. Amazon AWS en CloudFlare hadden er ook last van, maar de schuld bleek bij het Zweedse Telia te liggen. Telia Carrier is een van de tier1-netwerkaanbieders en beheert een omvangrijk glasvezelnetwerk, waarmee de aanbieder verantwoordelijk is voor een belangrijk deel van de internetbackbone. CloudFlare is een content delivery network, of cdn, en moet dankzij zijn vele verbindingen met internet exchanges snelle en stabiele verbindingen bieden.

CloudFlare detecteerde afgelopen vrijdag een flinke packet loss bij Telia Carrier, maar het bedrijf loste dat probleem snel op. Maandag was het weer raak en dit keer waren de problemen omvangrijker, zo blijkt uit een grafisch overzicht dat CloudFlare heeft opgesteld. "Omdat transitproviders normaal gesproken erg betrouwbaar zijn, verhelpen ze hun problemen meestal snel. In dit geval gebeurde dat niet en moesten we onze poorten met Telia sluiten", schrijft het bedrijf.

Packet loss op 20 juni, gemeten door CloudFlare

De cdn registreerde grote hoeveelheden 522-http-foutmeldingen, als indicatie dat zijn servers die van zijn klanten niet meer konden bereiken. CloudFlare probeerde verkeer om te leiden naar andere, in de woorden van het bedrijf 'beter presterende providers', maar kon niet voorkomen dat de problemen gevolgen hadden voor klanten en internetgebruikers.

CloudFlare gebruikt het border-gatewayprotocol om de datapakketjes te routeren. "Bgp werkt goed om interconnecties stabiel te houden, maar het heeft geen mechanisme om packet loss en prestatieproblemen te detecteren." Het bedrijf zegt zelf te werken aan een mechanisme om actief packet loss te registreren en verkeer om te leiden, maar dit wordt alleen nog gebruikt bij afgelegen en kleine locaties. In de komende twee weken zou CloudFlare deze technologie naar meer locaties uitbreiden.

De directeur van CloudFlare noemt de betrouwbaarheid van Telia over de afgelopen zestig dagen 'onacceptabel'. Zijn bedrijf heeft de afhankelijkheid van Telia's netwerk verlaagd totdat de problemen opgelost zijn. Telia heeft nog niet gereageerd. Volgens The Register ging het om een menselijke fout, waarbij iemand een router verkeerd instelde. De site claimt dat een technicus bij de configuratie van een router Hongkong en Europa door elkaar haalde, waardoor het misging. Niet duidelijk is waar de site die informatie vandaan heeft en Telia heeft de informatie niet bevestigd.

Reacties (53)

Als een T1 provider problemen heeft, heeft dit directe gevolgen voor de hele stabiliteit van internet/Wan verbindingen.
Cloudfare is daar dan direct de dupe van en hier valt weinig tegen te doen behalve te switchen naar andere providers. Hiervoor moet je changes doen aan je infrastructuur terwijl je niet weet hoe lang de outage/storing gaat duren. Dus de investering voor Cloudfare om deze changes te doen vs de tijd die Telia erover doet om het te repareren is altijd een lastige keuze. Daarbij zijn er kosten aan verbonden ook als je later bij Cloudfare weer terug wilt.

Je mag van een T1 provider wel enige profesionaliteit verwachten maar ook hier werken mensen en die kunnen fouten maken met grote gevolgen. Hiervoor heb je SLA's
KPN heeft niet zo gek lang geleden ook fouten gemaakt waardoor er grote problemen ontstonden.

nieuws: KPN-klanten kampen met storing op vaste aansluiting - update 2
nieuws: Ministerie laat onderzoek doen naar grote KPN-storing Zuid-Holland
nieuws: Gebrek aan backup in knooppunt leidde tot KPN-storing Rotterdam

Het netwerk zoals het nu gebouwd is, is wel (vaak) redundant maar niet eenvoudig waardoor het niet makkelijk is om snelle changes te maken.

edit: typo Telio moet Telia zijn

[Reactie gewijzigd door COW_Koetje op 21 juni 2016 14:15]

Als een T1 provider problemen heeft, heeft dit directe gevolgen voor de hele stabiliteit van internet/Wan verbindingen.
Cloudfare is daar dan direct de dupe van en hier valt weinig tegen te doen behalve te switchen naar andere providers. Hiervoor moet je changes doen aan je infrastructuur terwijl je niet weet hoe lang de outage/storing gaat duren. Dus de investering voor Cloudfare om deze changes te doen vs de tijd die telio erover doet om het te repareren is altijd een lastige keuze. Daarbij zijn er kosten aan verbonden ook als je later bij Cloudfare weer terug wilt.

Ik krijg het gevoel dat je niet helemaal weet hoe Cloudflare werkt. Zij kopen niet bij een ISP, maar gebruiken BGP multi-homing om zich te verbinden met heel veel ISPs. Vaak is dit direct dmv peering op ongeveer 81 plekken in de wereld. Soms is dit indirect, middels transit, waarbij een derde als Telia het verkeer naar haar klanten doorzet. Nu heeft Cloudflare meerdere transit providers. Normaliter is Telia preferred voor een deel van de klanten vanwege directere verbindingen. De misconfiguratie bij Telia maakt het heel rot voor de systemen van Cloudflare om te zien waar het verkeer heen moet. Waar het volgens de routeringstabel en de geschiedenis het beste via Telia gestuurd kan worden, blijkt dat nu niet zo te zijn, omdat Telia het intern eest via Hongkong stuurt. Dan moet je dus handmatig gaan klooien in wat een supergaaf dynamisch systeem is.

Ik snap hoe CloudFlare werkt en de shortest route systeem dat zij hanteren. Door inderdaad alle verkeer te routeren via HongKong ging het behoorlijk fout bij Telia.

De keuze om dus handmatig te gaan zitten aanbrengen van Changes is dus niet iets dat je graag wil gaan doen qua risico en kosten. Afgeleid van de Tweet van CloudFlare hebben ze dit dus nu wel gedaan en de priority van Telia verlaagt. Schijnbaar zijn er al meerdere incidenten geweest vooraf aan deze.

Tja het blijft mensen werk. Onacceptabel of niet, dat wijst een contract uit, niet de mening van CloudFlare. (Alhoewel ze wel veel invloed hebben)

Telia is een carrier die voornamelijk via peering verkeer uitwisselt. In dit geval zijn er meestal geen contracten opgesteld, maar meer een gentlemen's agreement waarbij alle partijen beloven een zo goed mogelijke dienst te leveren, maar zonder penalties en garanties.

Betrouwbaarheid van alle grote carriers is relatief laag de laatste jaren door de enorme groei van verkeer. Waar de lokale IX-es (AMS-IX BE-IX etc.) sterk gegroeid zijn, is dat een stuk lastiger voor internationale carriers. Zij moeten namelijk nieuwe kabels graven of op de zeebodem leggen, en zijn daar allemaal ook druk mee bezig (momenteel 6 high capacity kabels in ontwikkeling).

In dit geval lijkt het om een slecht getimede BGP change te gaan, welke plaatsvond in het midden van de nacht aan de Hong Kong kant van Telia, kwalijke zaak uiteraard, maar kan gebeuren. Wat mij verbaasd is dat CloudFlare nu aangeeft dat ze al 60 dagen problemen hebben, maar zonder data vrij te geven om dit te onderbouwen. Lijkt me meer naming and shaming dan een constructieve dialoog.

[Reactie gewijzigd door MMaI op 21 juni 2016 16:37]

Goede reactie, waarvoor +1. Maar je haalt volgens mij hier wel CloudFlare en CloudFront door elkaar, of heeft CloudFront ook recent dergelijke carrier problemen gehad?

Amazon AWS zoals in het artikel staat gebruikt Amazon CloudFront. Hoewel de informatie stroom ervan enorm onduidelijk is zal er wel ergens een bericht zijn van Amazon die naast Cloudflare ook loopt te klagen.

Correct, heb het aangepast.

CloudFlare != CloudFront

Bovendien kwamen grote internationale internet problemen vroeger veel vaker voor. Zie bijvoorbeeld: nieuws: Kabelbreuk verstoort dataverkeer tussen Europa en VS

Ik snap best dat CloudFlare dit aankaart, ze hebben veel klanten met een SLA en downtime kost CloudFlare dus een hoop geld.
De CloudFlare blogs zijn vaak meer informatief en gaan ook over issues in hun eigen bedrijf en hoe ze die dan oplossen. Dus ik denk niet dat hun intentie was om aan naming and shaming te doen.

Tja, CloudFlare had natuurlijk i.p.v. Telia te noemen neer kunnen zetten dat het om een grote tier 1 provider ging. Maar waarom zou je het beestje niet bij naam mogen noemen?

Omdat ze dit bij bijvoorbeeld Level3 en Zayo (voorheen AboveNet) niet doen bij outages. Verder is CloudFlare zelf verantwoordelijk voor de failover van dit soort netwerken, en ligt de "fout" bij CloudFlare door verkeer niet automatisch over een andere route te laten lopen.

De schuld (niet de oorzaak) bij een Tier 1 provider leggen is simpeler, maar niet correct.

de schuld, ligt waar die hoort, als tier1 op, heb je gewoon de plicht om 'gekwalificeerd personeel in te zetten, om goede testprocedures te hebben, en op natuurrampen na, tegen de zes negens aan te zitten, dat is afgelopen 2 maanden duidelijk niet gelukt, en kun je prima onacceptabel vinden, en mag je dan ook prima comuniceren, de vraag of CF hier eigenschuld-dikke-bult heeft, ik denk dat je niet heel erg veel anders kunt dan bpg-routering, en daar zitten nu eenmaal bepaalde mechanieken niet (voldoende) in. dus als we over schade gaan praten, heb je een prima argument om te zeggen ja CF de schade zou veel minder zijn als jullie je eigen system ook beter zouden uitrusten, maar met alleen die stelling doe je de siuatie ook geen recht

Tier-1 netwerken doen alleen maar met peering, het liefst ook settlement free. Telia is een Tier-1 dus die maken geen gebruik van Transit providers

Het toont aan de andere kant wel aan hoe kwetsbaar deze infrastructuur is. Er is blijkbaar minder redundantie dan veel mensen denken. Bij een storing als deze blijkt maar weer eens hoe belangrijk deze infrastructuur is. Niet alleen voor de consument maar ook zakelijk en voor veiligheidsdiensten. De afhankelijkheid neemt alleen maar toe.

Redundant is een leuk woord maar betekend ook vaak geld, het kost veel geld en dat moet iemand betalen.

Natuurlijk is infrastructuur kwetsbaar het is ook vaak een domino effect. Gaat er hier iets mis dan verderop en nog verderop ook weer. Dat is het probleem met complexe netwerken die alleen maar complexer worden.

Het zijn dan nog steeds mensen die het beheer doen en ja mensen maken fouten en dan kun je wel eens problemen krijgen.

If you pay peanuts you'll get monkeys.

Natuurlijk kun je overal een prijs opplakken met het commentaar dat het ergens anders net wat goedkoper kan,
alleen betekent het net zo vaak dat het met tekortkomingen komt.

Belangrijk is om een fatsoenlijke risico-analyse te maken en in hoeverre bepaalde risico's acceptabel zijn.


Mocht de verklaring daadwerkelijk plausibel zijn, dan zou ik toch met spoed het systeem eens gaan doorlichten. Systeem kan en mag niet gaan haperen bij het falen van een router.

Je zou het zelfs zo moeten instellen dat wanneer er een bepaalde instelling verkeerd staat, dat er alarmbellen af zouden moeten gaan. Misschien dat een deel last van heeft, maar het grootste deel van het bedrijfsproces loopt dan gewoon door.


En het blijft gissen maar ik vind het een vreemde erklaring. Verkeerd ingesteld icm menselijke fout klinkt heel mooi,
maar volgens is bij grotere projecten de procedure eerst draaien in een virtuele omgeving en vervolgens kopieer je de settings. Niet op de uiteindelijke plaats zitten rommelen.

Klinkt allemaal mooi wat je schrijft, of het in de praktijk ook zo werkt betwijfel ik.

Een foute instelling is een foute instelling en die heeft dan een domino effect.
Een foute instelling moet je eerst achter komen, dat los je niet zo maar op door te denken dat een systeem daar automatisch achterkomt en meteen alarmbellen afgaan. Daar is het allemaal te complex voor.

Er wordt enkel gezegd dat door een menselijke fout een hongkong configuratie op een europese router terecht is gekomen. Waar deze menselijke fout uiteindelijk gebeurd is, wordt niet vermeld.

Stel dat de router verkeerd gelabeld is, dan kan je nog zo'n waterdicht systeem hebben waarbij de configuratie 1000x gechecked wordt maar dan zal deze toch nog op de verkeerd gelabelde router landen. Zie dat maar in hetzelfde QA process te ondervangen

BGP kun je maar heel beperkt in een virtuele omgeving testen. Daarnaast is ook de vraag wat de prioriteit van deze actie was, het zou zo maar eens kunnen dat het bijvoorbeeld urgent was.

Het internet orgineel was gebouwd om hardstikke reduant te zijn. Het probleem is dat de massa dit niet makkelijk vond en alles lekker gezellig centraal willen bv Als whatsapp op 1 dag stopt dan hebben veel mensen een probleem en veel chaos en schade maar als een P2P chat werd gebruikt dat maakt het weinig uit als de developer ermee kapt, je chats kunnen nog gewoon doorgaan en grote kans is dat je het niet eens merkt dat de servers gestopt zijn.

Dit heeft niets te maken met redundantie, dit was een configuratiefout.

Voordat je een router instelt als T1 provider mag je toch wel aannemen dat dit minimaal door 2mensen gecheckt word.

Als anders je netwerk plat gaat heb je een groot probleem net zoals nu.

Bij programmeren is het zeer gebruikelijk dat je veranderingen gecontroleerd worden door een 2e persoon, de 'reviewer'. Is dat niet zo bij dit soort belangrijke netwerk instellingen?

Zouden ze eens moeten proberen dan

Klinkt leuk maar de praktijk is anders. Je hebt een storing moet een instelling aan een router veranderen, het is 4 uur s'nachts. Je moet dan wachten op nummer 2 die jou verandering in overleg moet goedkeuren. Dat duur misschien een uur voordat hij er is. In die tijd geen verandering en storing die blijft bestaan

Dit was alleen niet om 4 uur 's nachts maar gewoon tijdens werk uren.

Daarnaast geldt natuurlijk ook bij storingen dat de storingsdienst met twee man zou moeten werken.

"werkuren"" op het internet is natuurlijk een zinloze term.
Het betrof kennelijk een Honkkong router waar het toen buiten werktijd was. Duurt dan even voordat men doorheeft wat er misgaat.
Slordig nietemin maar wat complexer dan je voorstelt.
Je mag aannemen dat er wel meer mensen betrokken zijn bij een wijziging. Bij BGP kan het verkeer netjes afgeleverd worden , alleen helaas op het verkeerde adres. Fouten traceren kost dus dan ook even tijd. Oplossen van een rpobleem kost wederom tijd voordat alles doorgegeven is.. elk uur is er dan een teveel maar helaas onoverkomenlijk soms.

In dit geval ging het om config van een router uit hong kong die kennelijk op een europese router is gezet, maar dit is wel vanuit sweden geregeld. De enorme packetloss die optreed komt niet doordat de hong kong router denkt dattie in europa staat, maar dat de europese router aangeeft dattie eigenlijk in hong kong staat.

BGP kiest dan voor het kortste lijntje en stuurt verkeer uit de VS en EU (en deels ws ook midden oosten) door naar de verkeerde router die daarna z'n packets niet meer kwijt kan.

Werkuren op het internet zijn echter nog steeds geldig. Als er geen storing is (wat niet te zien is op het kaartje hierboven) dan wordt zo'n configuratie niet zomaar uitgerold dus ga er er maar van uit dat er meerdere mensen in de buurt waren.

Geen idee waarom je meent BGP uit te moeten leggen.
Natuurlijk zijn er geen kantoortijden op het internet. da tis wereldwijd en de tijd is overal anders. Ik geef je een link naar dat verschijnsel voor beter begrip.
Je kunt hooguit tijd relatief aan utc geven.
https://nl.wikipedia.org/wiki/UTC

Omdat je niet door hebt dat dit vanuit zweden is gebeurt. Als je de bron er even bij pakt dan zie je dat dit gewoon tijdens normale europese werktijden is gebeurt en had dit gewoon niet moeten kunnen gebeuren.

Anders slaat bbo1970 z'n comment ook nergens op. Ja het is vast ergens op deze aardkloot 4 uur 's nachts, maar dat betekent niet dat een dergelijke configuratie ook 's nachts wordt gedaan. Sterker nog ik mag hopen van niet, want dan gaan we dit soort dingen veel vaker zien.

Het is volstrekt onwaarschijnlijk om router updates tijdens de eigen kantooruren te doen. Als je enige ervaring hebt met maintenance hours dan weet je dat. Het meest waarschijnlijke is dus dat in zweden laat nog een router verkeerd geconfigureerd is (klopt ook met bekende zaken) en dat men pas later erachter kwam dat al het verkeer verkeerd afgeleverd werd. Pas daarna kun je actie gaan ondernemen maar dan ben je al weer wat uren verder.

"zou moeten"
Dat soort redundantie is bij de meeste bedrijven al lang wegbezuinigd. Zie hier de gevolgen.

zouden moeten wat een mooie term. Een ideale wereld , mensen vervangen door robots die geen fouten maken tenzij de mensen ze verkeerd geprogrammeerd heeft en hun ai het nog niet opgespoord heeft.

Probleem is alleen dat als de "Work order" fout is, de reviewer het ook niet kan zien. Wat wel zou moeten gebeuren is dat het netwerk na aanpassing gecontroleerd wordt op datastromen en stabiliteit.

Je wil niet weten hoe vaak dit gebeurd in de praktijk, maar meestal is men wakker genoeg om het binnen 15 minuten weer terug te draaien. Zo zijn er genoeg verhalen van providers die via BGP per ongeluk het hele internet claimen en zichzelf "dood" DDOS'en en vertraging voor andere partijen veroorzaken.

Hilarisch af en toe. Turkije die zomaar schreeuwt "hoooiii wij zijn Youtube!!!"

Ik heb vroeger bij een "tier2" partij gezeten die internet pakketjes in Europa routeerde, was er een dev dus kan er misschien ietsover delen.
Als reactie op je bericht: was het maar zo simpel , je hardware beinvloed b.v. al je "work order" (zoals hierboven genoemd in een andere reactie op je bericht).

Wij hadden Brocade hardware, als je daar changes voor wou doen was het "gelijk live", wij hadden dan tools die de "config verschillen" stuurde naar de collega's, maja als er een fout inzat was het kwaad al geschied.
Voor de duidelijkheid deze hardware is enorm duur (dedicated hardware, eigen OS voor lage latency), ik weet niet precies hoe duur maar wel dat het 10k+ is.

Uiteindelijk gingen wij naar een systeem toe die de config "genereerde" en de network engineers hoefde deze enkel nog te 'plakken in de router', daarmee voorkom je de nodige fouten maar alsnog is het geen waterdicht systeem.

Waar ik wel nieuwsgierig naar ben, of de leveranciers van CloudFlare heel erg blij worden van deze nieuwe software van hun die packet-loss detecteert. Kan me voorstellen dat CloudFlare dan hele dure contracten moeten afsluiten om ineens zoveel verkeer van partij A naar partij B om te zetten (in de transit wereld betalen bedrijven voor elke Mbit).

Cloudflare biedt content delivery services waaronder ddos bescherming. Zij geven echt niet om een paar Mbit Hun leveranciers vinden het natuurlijk fijn dat Cloudflare redundantie inbouwt.
Dat zullen best 'hele dure contracten' zijn, maar het koste wat het kost!

Hehe idd. Een pull requestje voor aanpassingen van routerinstellingen zou wel op zijn plaats zijn als het zulke gevolgen kan hebben

Dit soort fouten zouden met clouddiensten tot het verleden behoren zeiden de voorstanders, want een ander deel van de wolk pakt het op wat geen storing of capaciteit problemen heeft. Werkt dus niet helemaal zoals bedacht.
Ik heb zelf nog steeds het liefst dedicated servers dan cloudservers, bij een grote storing weet ik waar het zit.

Cloudflare lost dit ook op maar met BGP kan packetloss niet gedetecteerd worden, alleen een echte outage. Verder is Telia zo'n grote speler (tier-1 netwerken kunnen het hele internet bereiken) dat je dit niet zo maar kan opvangen met andere providers. Waardoor Cloudflare dus een verhoogd aantal 522's detecteerde (CF's eigen status code dat de origin niet gevonden kan worden).

Uiteindelijk gaat CF automatisch switchen bij packetloss (een systeem wat ze al in kleinere dc's hebben draaien) en dan haal je dus weer sneller een hoge uptime

[Reactie gewijzigd door GrooV op 21 juni 2016 14:35]

Ondanks dat Cloudflare cloud in z'n naam heeft is het helemaal geen cloud service.

Hoezo niet?

Hier als gebruiker idd sommige cloudflare websites die wel niet wel niet tebenaderen waren, nu weten we dus ook waarom

Is voor zulke fouten als dit dan geen backup systeem actief dat in werking zou moeten treden als het fout gaat?
Ik bedoel niet dat ik niet zonder internet zou kunnen maar je zou toch verwachten dat er naast dit systeem nog een systeem draait die dit op hoort te vangen.

Jij snapt er weinig van
Iedereen gebruikt BGP.

[Reactie gewijzigd door Spykie op 21 juni 2016 12:12]

Het artikel heeft jou een klepel gegeven maar de klok moet nog komen zie ik.

BGP is dé manier om op het internet de routing te doen. Kun jij wel iets anders gebruiken maar dan praat de rest van de wereld niet met je.

Het BGP protocol is het standaard protocol voor internet routering, het is dus niet een vreemde keus van Cloudflare.

Currently, BGP version 4 is the accepted standard for Internet routing and has essentially replaced the more limited EGP3

Ben benieuwd of een opvolger van het BGP protocol in de maak is die rekening houdt met latency, packetloss en wellicht ook afspraken over symmetrische routing kan verzorgen.

Op dat gebied liggen zeker nog verbeter mogelijkheden maar echte vooruitgang zie ik nog niet gebeuren.

Ehmm...
Alle reacties gaan in op jouw misverstand omtrent BGP, en niemand op je netneutraliteitsopmerking.... Lezen kerel, lezen.

Ter verduidelijking:
Het internet zou op dit moment niet bestaan zonder BGP, 'Border Gateway Protocol'. Dit is het protocol dat alle ISP's gebruiken om met de 'buren' te babbelen en zo de route naar andere netwerken 'uit te vogelen' (simplistisch gezegd). Lees er maar eens wat over.

BGP is geen 'zwakke infrastructuur', daar heeft het geen donder mee te maken.

Pfff, ok. nu echt offtopic verder speciaal voor AMS76:

Ik bedoelde dat ik had gehoopt dat de offtopic reacties v.w.b. het artikel n.a.v. mijn reactie beperkt zouden blijven tot door mij aangekaarte maatschappelijk twijfelachtige wenselijkheid van de core business van partij in kwestie. Helaas kwamen de ongepaste reacties dus enkel in het kader van betweterig gedoe over een protocol; van mensen die niet doorhadden dat ik een heel andere bel luidde dan die, die zij zelf mijn argument in gefietst hebben.

1. Als boven: Men heeft mij misverstaan, dat is correct. Kwestie van begrijpend "lezen kerel, lezen" dan komt men er hopelijk alsnog uit.
2. "zou niet bestaan zonder" => En dus was het goed. (<inderdaad; dat heet sarcasme. Niet een sterke stijl, maar hier zeer zeker gepast.)
3. BGP kan mij geen drol schelen; Ik wil het niet eens weten. En met recht; zoals je ziet is bruikbaarheid (denk eindgebruiker) prima te beoordelen zonder de technische ins en outs van onderliggende infrastructuur te kennen.
4. Voor de duidelijkheid: Ik schreef niet "hé jongens en meisjes ik snap geen snars van dat protocol, leg mij dat eens uit en dan graag niet op geciviliseerde wijze of met Nederlandse volzinnen.
5. Terug naar de kern van het argument: Als gebleken is het niet robuust want het faalt op een simpele menselijke fout bij derde partij in de keten. Wat ik n.a.v. die observatie aankaartte was dat ik het zwak vond van een partij om zo'n groot risico te nemen met de nering van anderen en dan bij onvermijdelijk een keer falen met de vinger te gaan wijzen naar begin van die cascade bij andere partij. Als je een omstandigheid ziet aankomen die je gehele business kreupel kan maken, en daarmee die van zovele anderen.. dan doe je daar wat aan. Want alles wat fout kán gaan gáát een keer fout. Daarentegen maar afwachten en met het vingertje wijzen vind ik zwak. Maar zoals ik al zei; ik wist niet dat het probleem algemeen geaccepteerd (gedrag) is. Doch blijft het in feite zwakke infrastructuur. Punt, basta.

Als er nóg iemand komt die mij wil uitleggen wat BGP is/doet/whatever dan stop ik met reageren. Tenzij er weer impliciet danwel expliciet wordt gepunnikt aan mijn waardigheid -alsof ik BGP moet kennen- -Alsof iets "mijn misverstand" is- -Alsof ik verminderd alfabeet ben- Dat vind ik te kinderachtig voor verondersteld volwassen tweakers, dus dan corrigeer ik zo'n mening nog even. Tenminste als en/of wanneer ik daarvoor tijd heb.

Misschien moet je dan je originele reactie zelf nog eens doorlezen, en zie je dan in waarom je zoveel reacties krijgt over BGP en vrijwel niets over de netneutraliteit.

BGP heeft overigens nog steeds niets met een 'zwakke infrastructuur' te maken, maar goed, ik zal er niks meer over zeggen...

@AMS76
"Je kent zelfs je eigen reacties niet"
"Ik heb nog steeds gelijk lekker puh"
"loederige knipoog"

Discussie van een f*cking week geleden, en je voegt -nog steeds- niks toe!
Geen tijd voor >> .. vul zelf maar in (ik houd het netjes).