Problemen met KPN verbindingen

[pennenlikker]

Goedemiddag,

Wij hebben afgelopen uur problemen met KPN verbindingen, met name dat RDP verbindingen niet kunnen worden opgezet naar onze servers waardoor veel gebruikers niet kunnen werken. Dit gebeurt op drie verschillende plekken in het land, klanten met een andere provider hebben tot nu toe geen last.

Op de KPN site zijn geen storingen bekend.
Zijn er meer mensen met problemen? Sta nu al meer dan 20 minuten in de wacht bij KPN

Thanks!

[[Mad Max]]

Het enige wat ik kan melden is dat wij hier at random sites niet kunnen benaderen. Waaronder Tweakers....
En dat is dus op een zakelijke KPN internet verbinding.

[C0SMiC NL]

Hier in Zwolle ook continu uitval en bepaalde sites zijn dan wel en dan weer niet te bereiken.

[RnB]

Ik krijg steeds de melding dat mijn UniFi Cloud Key offline is. Echter wanneer ik deze probeer te bereiken, is er niks aan de hand.

Regio Almere, Internet en TV Glasvezel.

[Henk007]

Hier hetzelfde, sites vaak niet bereikbaar via een Telfort DSL verbinding =Kpn

[ Voor 3% gewijzigd door Henk007 op 06-06-2019 13:10 ]

[[Mad Max]]

Mijn collega gaat de uitdaging aan om eens aan KPN te vragen wat er aan de hand is.
Wanneer wij wat weten, laat ik dat even weten.

[ehtweak]

FYI:

https://www.allestoringen.nl/storing/kpn
https://www.allestoringen.nl/storing/kpn/kaart/
https://storingen.help/kpn/

[ Voor 24% gewijzigd door ehtweak op 06-06-2019 13:11 ]

[Plenkske]

Hier ook het probleem net gehad dat een aantal sites niet werkte. Eventjes waren het geen sites waardoor ik dacht dat het aan mijn DNS lag. Maar daarna was het random. Nu lijkt alles weer goed te zijn *knocks on wood*

KPN Glasvezel regio zuid-oost brabant.

[[Mad Max]]

Er is een landelijke storing bij KPN. Oorzaak is nog niet bekend, maar ze zijn er druk mee bezig.
Aldus de BSD van KPN.

Er kwam ook nog een onduidelijke opmerking voorbij dat het aan een energieleverancier kan liggen...

[ Voor 30% gewijzigd door [Mad Max] op 06-06-2019 13:13 ]

[krakendmodem]

Hier ook KPN en ook problemen bij o.a. het benaderen van Tweakers. Aanpassen van DNS helpt niet.

Via KPN 4G weer geen problemen.

[pennenlikker]

Ik had net heel even een RDP verbinding die heel even werd opgezet en daarna meteen werd verbroken. Had KPN net aan de lijn, na een half uur. Er is een grote storing bij KPN groot zakelijk op het moment.

Wel netjes dat ze dit goed op de site zetten.

[thePiett]

Hier met KPN glasvezel in de buurt van Utrecht ook random websites die niet werken of langzaam laden.

Edit: wat is die website van KPN toch irritant. Je moet per se een postcode check doen om iets van storings-informatie te krijgen, en die meldt natuurlijk dat er geen storing is op mijn adres (terwijl er blijkbaar toch echt wat aan de hand is)

Is er ergens van KPN zelf een verstopte lijst met storingen en meer informatie?

[ Voor 62% gewijzigd door thePiett op 06-06-2019 13:21 ]

[iTeV]

Lijkt op een BGP hijack/leak. Een MTR naar kpn.nl werd in eerste instantie geroute naar een IP'je van chinanet. Nu lijkt het OK te gaan.

[FunkyBro]

Hier in Zwolle zelfde probleem, RDP naar kantoor werkt random niet en sites niet bereikbaar.

[Plenkske]

Misschien is er iemand boos geworden vanwege het nieuws omtrent Xs4All

[DutchCrownNL]

Hier in Amsterdam het zelfde, ook Tweakers was niet bereikbaar.
Een VPN verbinding naar kantoor blijft overigens wel actief.

[Brummetje]

pennenlikker schreef op donderdag 6 juni 2019 @ 13:15:
Ik had net heel even een RDP verbinding die heel even werd opgezet en daarna meteen werd verbroken. Had KPN net aan de lijn, na een half uur. Er is een grote storing bij KPN groot zakelijk op het moment.

Wel netjes dat ze dit goed op de site zetten.

Wij hebben hier gewoon KPN Prive en ook daar is het probleem aanwezig.

[pennenlikker]

Brummetje schreef op donderdag 6 juni 2019 @ 13:25:
[...]


Wij hebben hier gewoon KPN Prive en ook daar is het probleem aanwezig.

Dat heb ik tegen de man van KPN ook gezegd, maar dat was niet waar volgens hem.
Ook is er volgens KPN nog steeds niets aan de hand:

[ Voor 4% gewijzigd door pennenlikker op 06-06-2019 13:28 ]

[Maarten_E]

Hier in Den Bosch (Telfort) geen problemen, fingers crossed dat het wel vlug is verholpen.

[etienne001]

Het gaat hier in Zutphen nu wel weer een 15 min stabiel, daarvoor was het geregeld aan/uit

[pennenlikker]

Lijkt hier ook weer goed te werken, hopen dat het zo blijft!

[StephanVierkant]

Via Telfort DSL kon ik Tweakers niet bereiken en GitHub, WhatsApp, Twitter, Telegram, Telegraaf waren traag. Niet dat ik laatstgenoemde site veel bezoek, maar het viel me op dat allestoringen.nl die sites ook als problematisch liet zien. Via Telfort 4G werkte het beter.

[Step]

Het staat ook al op de Tweakers main page

[StephanVierkant]

https://twitter.com/wbontekoe/status/1136592757194145793

@wbontekoe: Wat is er aan de hand @KPN ? Lijkt wel bijna bgp hijacking? https://t.co/R9iTR9p62h

Geen idee wat hiermee bedoeld wordt en of dit relevant is. Iemand duiding?

[Beaves]

Zeker relevant, wat met BGP hijacking bedoeld wordt is dat een andere provider de IP space van KPN adverteert en daardoor verkeer afvangt wat eigenlijk naar KPN moet gaan. De provider (in China) die het nu lijkt te adverteren doet dit wel vaker, de precieze reden is mij niet bekend.

[DataGhost]

StephanVierkant schreef op donderdag 6 juni 2019 @ 14:11:
https://twitter.com/wbontekoe/status/1136592757194145793

@wbontekoe: Wat is er aan de hand @KPN ? Lijkt wel bijna bgp hijacking? https://t.co/R9iTR9p62h

Geen idee wat hiermee bedoeld wordt en of dit relevant is. Iemand duiding?

Hetzelfde als wat @iTeV zei:

iTeV schreef op donderdag 6 juni 2019 @ 13:20:
Lijkt op een BGP hijack/leak. Een MTR naar kpn.nl werd in eerste instantie geroute naar een IP'je van chinanet. Nu lijkt het OK te gaan.

# whois 118.85.205.122 
inetnum:        118.84.0.0 - 118.85.255.255
netname:        CHINANET-BB
descr:          CHINANET BACKBONE NETWORK
descr:          China Telecom

Dat lijkt me niet iets wat je hoort te zien in een trace van een Nederlandse verbinding naar kpn.nl.

[mmjjb]

Beaves schreef op donderdag 6 juni 2019 @ 14:13:
Zeker relevant, wat met BGP hijacking bedoeld wordt is dat een andere provider de IP space van KPN adverteert en daardoor verkeer afvangt wat eigenlijk naar KPN moet gaan. De provider (in China) die het nu lijkt te adverteren doet dit wel vaker, de precieze reden is mij niet bekend.

Dat de records naar China Telecom lopen, hoeft natuurlijk niet te betekenen dat China Telecom ook de BGP records heeft uitgestuurd. Technisch gezien kan elke BGP provider dit natuurlijk foutief uitsturen.

Nou is dit niet voor het eerst en is het zeker aannemelijk dat het China Telecom zelf de oorzaak is. Kan iemand bevestigen waar de BGP records vandaan kwamen?

[Scorpio861]

Regio zeeland . geen internet via 4g netwerk meer ( zakelijk abbo)

Geen enkele site is nog bereikbaar.

[GrooV]

Volgens BGP Stream is er niks geregistreerd wat betreft BGP Hijacking op dit moment.

China telecom is wel aan het rommelen maar niet op KPN prefixes zo te zien

[ Voor 32% gewijzigd door GrooV op 06-06-2019 14:56 ]

[Charlie_Root]

DataGhost schreef op donderdag 6 juni 2019 @ 14:16:
[...]

Hetzelfde als wat @iTeV zei:

[...]

# whois 118.85.205.122 
inetnum:        118.84.0.0 - 118.85.255.255
netname:        CHINANET-BB
descr:          CHINANET BACKBONE NETWORK
descr:          China Telecom

Dat lijkt me niet iets wat je hoort te zien in een trace van een Nederlandse verbinding naar kpn.nl.

Zie vooral mijn tweede tweet. Een VPN verbinding die succesvol tot stand is gebracht terwijl het door China heen liep en terug naar KPN werd gerouteerd.

China: TEST PASSED.

[GrooV]

Dan is het toch geen BGP hijacking...

[Beaves]

Kan zeker wel, als de ISP die de prefixes adverteerd zelf na ontvangst het verkeer weer terugstuurt naar KPN bijvoorbeeld.

[menonv]

Vanaf zuiden des lands ook zeer gare verbinding gehad (KPN Stedelijk Glas), begon al rond 12:15 ongeveer, het werd namelijk erg rustig op onze synchronisatie tool. Daarna komen mensen binnen druppelen dat Nu.nl / telegraaf e.d. niet meer werkt. Collega's staan vast bij de Jan Linders omdat de pinautomaat het niet doet - en met vraag of iemand met cash kan komen. Tja, dan ga je wel even achter de oren krabben wie hiervoor flink op de vingers moet worden getikt.
of niet....

[GrooV]

AS4134 announced al sinds 2010 op dat subnet dus laten we even ophouden met onzin verspreiden

https://stat.ripe.net/wid...esource=118.85.205.0%2F24

Sterker nog , 118.84.0.0 - 118.85.255.255 is van China telecom

[ Voor 17% gewijzigd door GrooV op 06-06-2019 15:24 ]

[Charlie_Root]

GrooV schreef op donderdag 6 juni 2019 @ 15:24:
AS4134 announced al sinds 2010 op dat subnet dus laten we even ophouden met onzin verspreiden

https://stat.ripe.net/wid...esource=118.85.205.0%2F24

Sterker nog , 118.84.0.0 - 118.85.255.255 is van China telecom

Mijn screenshot laat het duidelijk zien. Ik weet niet waar dit 118 net vandaan komt, niet van mijn posts in elk geval.

Je kunt het ook goed zien via Ripe BGPlay..

[ Voor 4% gewijzigd door Charlie_Root op 06-06-2019 15:28 ]

[Soldaatje]

Het lijkt dan een DNS hijack?
Want dat is niet KPN IP.

[GrooV]

DataGhost in "Problemen met KPN verbindingen"

Charlie_Root schreef op donderdag 6 juni 2019 @ 15:28:
[...]


Mijn screenshot laat het duidelijk zien. Ik weet niet waar dit 118 net vandaan komt, niet van mijn posts in elk geval.

Je kunt het ook goed zien via Ripe BGPlay..

Ik weet niet wat het screenshot laat zien behalve een onvoltooide traceroute

[3raser]

GrooV schreef op donderdag 6 juni 2019 @ 15:35:
DataGhost in "Problemen met KPN verbindingen"

[...]

Ik weet niet wat het screenshot laat zien behalve een onvoltooide traceroute

Zelfs als onvoltooide traceroute is de route raar toch? Vanuit Nederland naar India en China om vervolgens weer bij KPN in Nederland uit te komen.

[ Voor 0% gewijzigd door 3raser op 06-06-2019 15:44 . Reden: Niet langs India ]

[menonv]

Ondertussen ook van andere onderzoekers informatie dat het "foutje - ahum" wel wat groter was dan alleen KPN. Ook verbindingen vanaf OVH Roubaix , Hetzner Duitsland en Belgie verliepen via China.

Overigens vernomen via @Charlie_Root / Retweet.

https://twitter.com/cm3r/status/1136612465813413889

[GrooV]

3raser schreef op donderdag 6 juni 2019 @ 15:39:
[...]

Zelfs als onvoltooide traceroute is de route raar toch? Vanuit Nederland naar India en China om vervolgens weer bij KPN in Nederland uit te komen.

Er wordt hier geroepen dat het om BGP hijacking gaat dus het zou fijn zijn als er gewoon een source en destination getoond worden.

Dat iets via China gerouteerd wordt zegt natuurlijk helemaal niks, misschien heeft KPN zelf gewoon een configuratie fout gemaakt .

Gewoon een kwestie van de kortste route adverteren en het verkeer gaat via jou, lang leve het BGP protocol!

Dat het niet wenselijk is dat snap ik

[ Voor 8% gewijzigd door GrooV op 06-06-2019 15:48 ]

[DataGhost]

Er wordt "lijkt" geroepen en ik had gewoon een random IP uit de screenshots gepakt waar een hoge ping bij stond, ik heb het niet met een luizenkammetje uitgezocht. En als je ziet dat dat random IP uit hetzelfde AS komt wat behoorlijk vertegenwoordigd is op bgpstream dan kan je alleen maar overhaaste conclusies gaan trekken natuurlijk. Normaal is het in ieder geval niet, en logisch ook niet, en voor een fout wel heel toevallig.

Maar ja, wie weet hebben ze het zelf verprutst inderdaad. Of Huawei heeft hun backdoor per ongeluk gedemonstreerd

Charlie_Root schreef op donderdag 6 juni 2019 @ 15:28:
[...]

Mijn screenshot laat het duidelijk zien. Ik weet niet waar dit 118 net vandaan komt, niet van mijn posts in elk geval.

Ook uit jouw screenshot, uit beide zelfs

[ Voor 20% gewijzigd door DataGhost op 06-06-2019 15:55 ]

[Charlie_Root]

GrooV schreef op donderdag 6 juni 2019 @ 15:46:
[...]

Er wordt hier geroepen dat het om BGP hijacking gaat dus het zou fijn zijn als er gewoon een source en destination getoond worden.

Dat iets via China gerouteerd wordt zegt natuurlijk helemaal niks, misschien heeft KPN zelf gewoon een configuratie fout gemaakt .

Gewoon een kwestie van de kortste route adverteren en het verkeer gaat via jou, lang leve het BGP protocol!

Dat het niet wenselijk is dat snap ik

Het is door/bij meerdere grote providers gemeld. Dus dat KPN een foutje heeft gemaakt is uitgesloten.

[Olaf]

KPN heeft een verklaring afgegeven:

"Door een foutieve configuratiewijziging in het netwerk bij een derde partij, een zogenaamde transitpartij in Zwitserland, werd het internetverkeer van een deel van de KPN-klanten niet meer goed afgehandeld. Doordat deze derde partij deze wijziging ongedaan heeft gemaakt, is dit weer hersteld."

nieuws: Storing bij provider zorgt voor landelijke pinproblemen in Nederland ...

[Charlie_Root]

Olaf schreef op donderdag 6 juni 2019 @ 16:12:
KPN heeft een verklaring afgegeven:
[...]


nieuws: Storing bij provider zorgt voor landelijke pinproblemen in Nederland ...

Ik vind het een hele knappe "fout" als je dan vanuit China besluit het verkeer van de "foute" ranges weer terug te routeren zodat de verbinding (met enige vertraging) weer werkt..

[3raser]

Olaf schreef op donderdag 6 juni 2019 @ 16:12:
KPN heeft een verklaring afgegeven:
[...]


nieuws: Storing bij provider zorgt voor landelijke pinproblemen in Nederland ...

Wie is die transit partij en heeft die apparatuur in zowel Nederland als China staan?

Charlie_Root schreef op donderdag 6 juni 2019 @ 16:15:
[...]


Ik vind het een hele knappe "fout" als je dan vanuit China besluit het verkeer van de "foute" ranges weer terug te routeren zodat de verbinding (met enige vertraging) weer werkt..

Is het niet mogelijk dat het verkeer vanzelf weer terug komt omdat ze in China doorhebben dat die data daar helemaal niet thuis hoort? De routers daar zien voor welk IP adres de data bestemd is en sturen het gewoon weer terug. Als dat via een andere route gebeurt komt het bij toeval dus gewoon weer aan.

[ Voor 36% gewijzigd door 3raser op 06-06-2019 16:20 ]

[mmjjb]

3raser schreef op donderdag 6 juni 2019 @ 16:17:
[...]

Wie is die transit partij en heeft die apparatuur in zowel Nederland als China staan?

In de comment van @heuveltjes "AS21217".

[ Voor 22% gewijzigd door mmjjb op 06-06-2019 16:20 ]

[Mmore]

In die screenshot van OVH lijkt het om servers te gaan van China Telecom in Frankrijk, niet dat het verkeer ook echt via China is verlopen? Gezien de hostname "china-telecom.franco71.fra.seabone.net"

[Charlie_Root]

mmjjb schreef op donderdag 6 juni 2019 @ 16:20:
[...]


In de comment van @heuveltjes "AS21217".

Ik kom dat ASN niet tegen in de traceroutes, mtr's en BGP lookups die ik heb gedaan hier. Dus ik vind het een rare statement van KPN, zeker nu ineens al het verkeer via AS3320 word omgeleid. Denk dat er wel wat meer aan de hand was.

Net gekeken, dat AS nummer kwam naar voren om 11:00, de storing begon pas om 12:00

Short description: The new route 37468 4809 4134 21217 21217 21217 21217 21217 21217 13237 1136 has been announced

[ Voor 15% gewijzigd door Charlie_Root op 06-06-2019 16:46 ]

[Charlie_Root]

Mmore schreef op donderdag 6 juni 2019 @ 16:20:
In die screenshot van OVH lijkt het om servers te gaan van China Telecom in Frankrijk, niet dat het verkeer ook echt via China is verlopen? Gezien de hostname "china-telecom.franco71.fra.seabone.net"

Ik kwam uit op een chinees netwerk met hoge rtt:

descr: CHINANET backbone network
descr: Data Communication Division
descr: China Telecom

[GrooV]

Charlie_Root schreef op donderdag 6 juni 2019 @ 16:29:
[...]

Ik kwam uit op een chinees netwerk met hoge rtt:

descr: CHINANET backbone network
descr: Data Communication Division
descr: China Telecom

Dat is gewoon de APNIC beschrijving, China telecom heeft ook pops/servers/routers buiten China natuurlijk

AS4134 is geen chinees netwerk maar gewoon een globaal netwerk

https://www.peeringdb.com/net/308

[ Voor 7% gewijzigd door GrooV op 06-06-2019 17:21 ]

[Charlie_Root]

GrooV schreef op donderdag 6 juni 2019 @ 17:20:
[...]

Dat is gewoon de APNIC beschrijving, China telecom heeft ook pops/servers/routers buiten China natuurlijk

AS4134 is geen chinees netwerk maar gewoon een globaal netwerk

https://www.peeringdb.com/net/308

Dat het een globaal netwerk is ben ik met je eens. Dat maakt dit ook prima duidelijk;
https://bgpview.io/asn/4134#downstreams-v4

Dit netwerk verbind China met "de wereld".

Maar als ik kijk naar de route die ik aflegde samen met de enorme rtt verschillen lijkt het me niet dat het verkeer in Amsterdam bleef of dat er kennelijk enorme overbelasting is geweest? Verder zie ik niets terug van een partij uit Zweden, ik ging via TATA rechtstreeks naar AS4134.

AS6453 (TATA)
AS4134 (CHINANET BACKBONE)
AS286 (KPN)

[ Voor 3% gewijzigd door Charlie_Root op 06-06-2019 17:49 ]

[GrooV]

Charlie_Root schreef op donderdag 6 juni 2019 @ 17:43:
[...]


Dat het een globaal netwerk is ben ik met je eens. Dat maakt dit ook prima duidelijk;
https://bgpview.io/asn/4134#downstreams-v4

Dit netwerk verbind China met "de wereld".

Maar als ik kijk naar de route die ik aflegde samen met de enorme rtt verschillen lijkt het me niet dat het verkeer in Amsterdam bleef of dat er kennelijk enorme overbelasting is geweest? Verder zie ik niets terug van een partij uit Zweden, ik ging via TATA rechtstreeks naar AS4134.

AS6453 (TATA)
AS4134 (CHINANET BACKBONE)
AS286 (KPN)

Jouw ISP a2b heeft geen peering overeenkomst met KPN, daar begint het al mee. Hierdoor moet er van transit partijen gebruik gemaakt worden, in dit geval wordt er voor Tata (tier 1) gekozen en daar is er iets misgegaan met de routing. Tata is zelf een tier1 network en heeft dus directe peering met KPN maar deze is niet gebruikt. Het lijkt er eerder op dat bepaalde routes niet meer mogelijk waren, mogelijk veroorzaakt door Safehost. Hierdoor is Tata via China telecom gegaan aangezien die route nog wel beschikbaar was en ook peering met KPN heeft

[WhatsappHack]

3raser schreef op donderdag 6 juni 2019 @ 16:17:
[...]

Wie is die transit partij en heeft die apparatuur in zowel Nederland als China staan?


[...]

Is het niet mogelijk dat het verkeer vanzelf weer terug komt omdat ze in China doorhebben dat die data daar helemaal niet thuis hoort? De routers daar zien voor welk IP adres de data bestemd is en sturen het gewoon weer terug. Als dat via een andere route gebeurt komt het bij toeval dus gewoon weer aan.

Uiteraard. Wel een duur pad qua hops, maar als die wel werkt en een ander pad niet: sure thing.
Helemaal door China is wel een flinke stretch als dat echt het geval is geweest, though.

[Charlie_Root]

GrooV schreef op donderdag 6 juni 2019 @ 18:24:
[...]

Jouw ISP a2b heeft geen peering overeenkomst met KPN, daar begint het al mee. Hierdoor moet er van transit partijen gebruik gemaakt worden, in dit geval wordt er voor Tata (tier 1) gekozen en daar is er iets misgegaan met de routing. Tata is zelf een tier1 network en heeft dus directe peering met KPN maar deze is niet gebruikt. Het lijkt er eerder op dat bepaalde routes niet meer mogelijk waren, mogelijk veroorzaakt door Safehost. Hierdoor is Tata via China telecom gegaan aangezien die route nog wel beschikbaar was en ook peering met KPN heeft

Kun je deze uitleg (alle punten) en de relatie van het probleem even uitschrijven? Zeker met de getoonde screenshots en traceroutes heb ik nogal wat vraagtekens bij de juistheid van jouw reactie

[Charlie_Root]

https://blogs.oracle.com/...fic-through-china-telecom

These “features” are caused by changes in how China Telecom exported these routes to Tier-1 telecoms during the leak.

[ Voor 9% gewijzigd door Charlie_Root op 07-06-2019 08:18 ]

[GrooV]

Charlie_Root schreef op vrijdag 7 juni 2019 @ 08:16:
https://blogs.oracle.com/...fic-through-china-telecom

[...]

Dat is toch het zelfde als wat ik zei?

Safehost zegt ga maar via Chinanet, Chinanet roept tegen de wereld, ga maar via mij.

Dit is ook geen BGP Hijacking zoals ik al zei maar BGP Leaking, helaas dagelijkse kost

Enige rare is dat jouw traceroute via Tata ging die zelf een tier1 is, die zou nooit via een tier2 moeten gaan.

Fout ligt zowel bij Safehost als bij Chinanet, helaas in het geval van de laatste komt dit erg vaak voor omdat ze hier zelf niks tegen doen

[ Voor 11% gewijzigd door GrooV op 07-06-2019 08:32 ]

[Charlie_Root]

GrooV schreef op vrijdag 7 juni 2019 @ 08:31:
[...]

Dat is toch het zelfde als wat ik zei?

Safehost zegt ga maar via Chinanet, Chinanet roept tegen de wereld, ga maar via mij.

Dit is ook geen BGP Hijacking zoals ik al zei maar BGP Leaking, helaas dagelijkse kost

Enige rare is dat jouw traceroute via Tata ging die zelf een tier1 is, die zou nooit via een tier2 moeten gaan.

Fout ligt zowel bij Safehost als bij Chinanet, helaas in het geval van de laatste komt dit erg vaak voor omdat ze hier zelf niks tegen doen

Wat ik miste in de uitleg van KPN; waarom ik via TATA ging. De uitleg van KPN was "het is niet onze schuld" maar miste alle onderbouwing. Oracle legt het beter uit.

Hijack of leak, geef het een naampje.

[GrooV]

Charlie_Root schreef op vrijdag 7 juni 2019 @ 09:23:
[...]


Wat ik miste in de uitleg van KPN; waarom ik via TATA ging. De uitleg van KPN was "het is niet onze schuld" maar miste alle onderbouwing. Oracle legt het beter uit.

Hijack of leak, geef het een naampje.

Waarom moet KPN dit uitleggen, je eigen ISP heeft geen peering met KPN. Je gaat nooit rechtstreeks naar KPN. Tata is een tier1, dus wordt die gebruikt

Daarnaast is internet routing best effort, niemand geeft garanties

[ Voor 4% gewijzigd door GrooV op 07-06-2019 09:30 ]