Storing bij internetknooppunt AMS-IX zorgde kort voor internetproblemen - update

Internetknooppunt AMS-IX heeft woensdagochtend een storing gehad waardoor providers en hostingproviders sessies moesten omleiden. Dit zorgde landelijk voor vertragingen en verbindingsproblemen.

De problemen lijken woensdag rond 10 uur te zijn begonnen. In de grafiek op de site van AMS-IX is te zien dat op dat moment het verwerkte verkeer in een keer veel lager is dan gebruikelijk. Allestoringen kreeg in korte tijd meer dan 500 meldingen binnen. Het verkeer is op het moment van schrijven teruggelopen naar 3,289Tb/s uitgaand verkeer en 3,049Tb/s binnenkomend verkeer, terwijl dit doorgaans rond dit tijdstip beide rond de 7,3Tb/s ligt. Het verkeer lijkt rond 11 uur weer toe te nemen.

TransIP meldt dat door de storing bij AMS-IX gehoste diensten tijdelijk verminderd bereikbaar waren. Het bedrijf heeft het verkeer omgeleid via een andere peeringpartner. Klanten zouden geen problemen meer moeten ondervinden. Tweak heeft het verkeer ook tijdelijk via een andere route lopen en zegt dat er 'prestatieproblemen' zijn op het corenetwerk.

Update 12:00 uur - In een reactie aan Tweakers laat een woordvoerder van AMS-IX weten dat tussen 10.20 uur en 10.45 uur een groot aantal bgp-sessies onderbroken werd, 74,5 procent van alle bgp-sessies die via AMS-IX lopen viel weg. Dat is opgelost door om AMS-IX heen te routeren. Inmiddels zijn de problemen opgelost, en neemt het verkeer toe. De oorzaak van dit probleem onderzoekt AMS-IX nog.

Reacties (89)

[Booster]

Let op: de Y-as van deze grafiek lijkt niet te beginnen bij 0
dus de constatering in het artikel dat er "vrijwel nul verkeer" zo zou zijn lijkt me incorrect.

De Y-as van de Daily stats grafiek op de website van de AMS-IX heeft ook een Y-as die niet bij 0 begint, maar daar is te zien dat er nog wel verkeer werd gemeten tijdens de storing: https://www.ams-ix.net/ams/documentation/total-stats

Dat het verkeer nog niet hetzelfde niveau heeft bereikt als voor de storing, komt mogelijk omdat aangesloten partijen hun routering nu hebben ingesteld om de AMS-IX te vermijden. Dat verkeer is er waarschijnlijk wel, maar via andere knooppunten.

[Reactie gewijzigd door Booster op 23 juli 2024 09:07]

[Kees]

In ams-ix termen is 3tbit/s overdag natuurlijk wel bijna nul

[skoozie]

Ik zou ongeveer 40% van normaal geen "bijna 0" willen noemen. als ik die grafiek bekijk doen ze dagelijks rond half 12 ongeveer 7.5Tb/s misschien dat er op een woensdag een iets ander niveau is dan op een dinsdag of een maandag, Maar daar verwacht ik niet heel veel verschil in.

Dit neemt niet weg dat door enkel dit plaatje niet vast te stellen is of het verkeer minimaal 3Tbps of 0Tbps is geweest. door de sampling en schaling van de grafiek kan je daar ook door op een verkeerd been gezet worden.

[Booster]

Gisteren was het rond hetzelfde tijdstip 7,5 Tb/s dus als ik moet kiezen tussen "bijna nul" of "40% van gebruikelijk" dan kies ik qua verslaggeving toch liever voor het laatste

Het was minder dan midden in de nacht, dus in dat opzicht is het in ieder geval heel weinig

[wisselwerking]

Voor verslaggeving wil je juist attentiewaarde, dus dan kies je voor bijna nul, ook al klopt dat niet 😉

[tweaknico]

Nee voor Clickbait & reclame wil je attentie waarde...
Voor verslaglegging wil je feitelijk juiste beweringen

En dat is niet het zelfde.

[wisselwerking]

Ik ben het helemaal met je eens. Wel heb ik het idee dat dit inmiddels wel wat door elkaar loopt.

[SirRosencrantz]

Ik heb de tekst iets aangepast, want eigenlijk heb je wel gelijk. Ik nam hier iets te veel dichterlijke vrijheid.

[Booster]

Dank je - ik postte mijn reactie vooral als verduidelijking voor de eerste lezers doordat het dieptepunt van de curve perfect samenkomt met de onderkant van de grafiek was het gemakkelijk om over het hoofd te zien. Zal mijn reactie ook nog aanpassen.

[DJSmiley]

Wat ik zag was dat het leek op vnl packetloss naar de routeservers.

https://smokeping.serveri...target=Transit.amsixtrunk

Daardoor zullen de nodige BGP sessies platgegaan zijn. Dat verklaard ook dat het niet helemaal down was, maar nog altijd ruim 3Tbit (Directe peerings).
Niet iedereen gebruikt de routeservers. Sommige partijen kiezen voor handmatige selectieve peerings

Geen idee of dat op alle datacenters was, maar iig op Nikhef. En daar zitten iig heel veel partijen aangesloten.

[dasiro]

Dat verkeer is er waarschijnlijk wel, maar via andere knooppunten.

dan spreken we niet meer over ams-ix verkeer, maar "gewoon" klantenverkeer naar het internet (waarbij klanten dus hosters of providers zijn, geen eindklanten)

[beerse]

Bij de verkeer gegevens van ams-ix vind ik het altijd grappig dat ik daar de performance plaatjes van cacti (pricewatch: Cacti) meen te herkennen. Al kan ik mij ook voorstellen dat het de achterliggende RRDTool is die ze gebruiken.

En ja, die grafieken hebben een stand dat de schaal (semi) automatisch gaat rond de actieve waardes, zodat je de benodigde details kan nazien maar helaas het 0-punt kwijt raakt.

[Beaves]

Denk dat dit wel handig is voor de algemene thread:

AMS-IX heeft last (gehad?) van een flinke hoeveelheid BUM (Broadcast, unknown-unicast en multicast) verkeer. BUM verkeer komt meestal voor uit een netwerk-loop, waarbij bijvoorbeeld broadcast verkeer eindeloos in een lus blijft loopen door alle switches in een segment. BUM verkeer wordt door de meeste apparatuur niet door gespecialiseerde asics afgehandeld, maar door de CPU van de switch zelf, die daar totaal niet geschikt voor is. Daardoor kan die switch zijn belangrijkste taak (het switchen zelf) niet meer behoorlijk uitvoeren met als gevolg packet loss.

Dat BUM verkeer wordt meestal veroorzaakt door of een bug, een fout in de configuratie of een verkeerd aangesloten device.

[vdoing]

Is het mogelijk om met genoeg aluminium folie hier over een Russische test te speculeren? Lijkt me leuk voor Reddit

[ANdrode]

Bedankt voor het uitschrijven van die afkorting! Dat was voor mij het missende puzzelstukje in de update die ik las.

[Beaves]

Update vanuit AMS-IX:

Dear Members/Customers,


As a follow up on the incident that took place earlier today (April 6th, 2022, at 10:18 CEST), we would like to share the root cause and what measures we are looking to take to limit the possibility of a similar event happening in the future.


09:00 CEST
AMS-IX engineers were working on switch stub-tc5-332, which was emptied from customers and was not handling production traffic, as part of the “[AMS-IX] (NOC24X7-80321) Equinix AM5 Scheduled re-patching and site load-balancing” maintenance. Part of the procedure is to perform tests and make sure that everything is validated and works as expected before putting to production. These are the so-called “snake tests”, which are utilized to ensure the line-cards, optics, and the final patching is working properly. The test traffic is isolated by utilizing specific non-production VLANs and this requires switch configuration changes and PXC connections remapping.


10:18 - 10:45 CEST
Following the aforementioned actions relating to PXC ports mapping and switch configuration changes, and due to human error, two interfaces were enabled ahead of time. This happened while the testing configuration was not yet finalized, and part of the production configuration was still applied. More specifically, the ports were part of the ISP Peering 501 VPLS instance, which led to a loop of BUM traffic back to the bridge domain. Consequently, MAC address station movement caused MAC learning issues which led to blackholing traffic. Hence, the BGP (peering) sessions on the platform were disrupted one by one.


10:45 CEST and onwards
The ports that were causing the issue were identified and disabled and traffic was gradually restored. More time was needed to recover to normal traffic levels, as some customers had either their BGP sessions disabled or were not announcing any prefixes (yet).


11:03 CEST
Most BGP sessions with the Route Servers were re-established by 11:03. Note that some customers/members opted to keep their BGP sessions disabled for longer.


Analysis of the event has shown that a combination of unexpected configuration state and a miscommunication led to the outage.

We are reviewing our internal procedures to make sure that we will optimize the internal communication and procedures in order to limit the possibility of a similar event happening in the future.


Once again, we sincerely apologize for any inconvenience caused by the outage.


Kind Regards,
--
AMS-IX NOC | AMS-IX

[Equator]

Dat verklaart de storingen die wij ondervinden met het gebruik van diensten als MS Teams.

[Reactie gewijzigd door Equator op 23 juli 2024 09:07]

[Minisculus]

Houdt er rekening mee dat ook in de Service Health portaal van Office365 een aantal diensten van MS te kampen hebben met Service degradatie. De kans bestaat dat dit dus los staat van wat er hier gebeurd is, hoewel het natuurlijk niet helpt.
De storingen van diensten van MS lijken in ieder geval nog niet volledig verholpen.

[Kenhas]

En die "Service Degradatie" kan niet komen door dit voorval? Als de verbinding weg valt tussen het datacenter en jouw pc, dan valt zoiets toch onder degradatie (die niet de schuld is van Office365)?

voor alle duidelijkheid: is een oprechte vraag, geen terechtwijzing of zo

[Minisculus]

Natuurlijk mogelijk, ik heb niet direct kijk op wat er aan de achterkant aan de hand is. Maar de servicestatus is voor veel (niet EU-lokale) Office365 tenants gebaseerd op de status van servers/hardware/netwerk in Amerika, niet op de bereikbaarheid vanuit NL.
Uiteraard kan het zijn dat deze storing zo groot is dat het "globaal" internet-infrastructuur heeft getroffen (iemand daar een opgeleide mening over?).
Ik vermoed alleen van niet, gezien de storing bij AMS inmiddels verholpen (lijkt) te zijn en de service-status in Office365 bij sommige tenants nog steeds degraded is

[Cergorach]

En die "Service Degradatie" kan niet komen door dit voorval?

In de afgelopen bijna 9 jaar ben ik nog nooit een service degradation tegengekomen op O365 die melding maakte van een extern internet knooppunt dat niet optimaal werkte.

[Cergorach]

OneDrive (for Business) had hierdoor oa. connectie issues, files konden bv. niet worden weggeschreven naar ODfB of een nieuwe verbinding opzetten met OD gaf een error.

[Acradavos]

De storing lijkt in ieder geval nog niet voorbij,

[CH4OS]

Kijkend naar de live statistieken zit er in elk geval meer snelheid in: https://stats.ams-ix.net/index.html

EDIT: En de lijn is verder stijgende.

[Reactie gewijzigd door CH4OS op 23 juli 2024 09:07]

[PC3-17000]

Hier ook. Onze internet provider heeft zelfs om 11:39 nog een mail uitgestuurd met de melding dat de storing nog actief is en dat we op de hoogte worden gehouden.

[Beaves]

AMS-IX heeft last (gehad?) van een flinke hoeveelheid BUM (Broadcast, unknown-unicast en multicast) verkeer. BUM verkeer komt meestal voor uit een netwerk-loop, waarbij bijvoorbeeld broadcast verkeer eindeloos in een lus blijft loopen door alle switches in een segment. BUM verkeer wordt door de meeste apparatuur niet door gespecialiseerde asics afgehandeld, maar door de CPU van de switch zelf, die daar totaal niet geschikt voor is. Daardoor kan die switch zijn belangrijkste taak (het switchen zelf) niet meer behoorlijk uitvoeren met als gevolg packet loss.

Dat BUM verkeer wordt meestal veroorzaakt door of een bug of een verkeerd aangesloten device, de kans dat "de Russen" dit gedaan hebben is verwaarloosbaar klein.

[Reactie gewijzigd door Beaves op 23 juli 2024 09:07]

[Cergorach]

Dat BUM verkeer wordt meestal veroorzaakt door of een bug of een verkeerd aangesloten device, de kans dat "de Russen" dit gedaan hebben is verwaarloosbaar klein.

Ik ben met je eens dat het altijd grijpen naar hackers uit <insert popular enemy> een veel te veel gebruikte verklaring is voor alles... Maar dat betekend natuurlijk niet dat de kans verwaarloosbaar klein is. Ik zou juist verwachten dat als je een methode heb die je kan reproduceren kan gebruiken om grote delen te verstoren van een netwerk en dat zich voordoet als 'onschuldige' misconfiguratie of defect, dat juist een uitstekende aanvalsmethode zou zijn...

[Beaves]

Maar dat is het dus niet, de aanvalsvector is veel te lastig, je moet namelijk in het netwerk (configuratietechnisch) terecht moeten komen wil je dit expres kunnen veroorzaken. Zomaar in een willekeurig datacenter naar binnen wandelen (wat niet kan) en even twee poorten op een AMS-IX switch aan elkaar koppelen heeft ook weinig zin omdat die poorten default uit staan en er bovendien ook MAC adressen vast staan, dus zomaar even een ander device op een bestaande poort prikken kan ook al niet omdat het MAC adres dan ander is.

[.oisyn]

dus zomaar even een ander device op een bestaande poort prikken kan ook al niet omdat het MAC adres dan ander is.

Dat is voor iemand die echt kwaad wil (en geen gelegenheidsvandalist) natuurlijk ook een koud kunstje. Je hebt alleen maar een device nodig die het MAC adres van een bestaande verbinding kan spoofen en je bent klaar. Dat is natuurlijk een koud kunstje voor iemand die een beetje handig is met een microcontroller. Die hang je dan gewoon tussen een bestaande verbinding en tel uit je winst.

[Cybertinus994]

Mac adres spoofen is nog heel veel simpeler dan met een microcontroller gaan klooien. In Debian is een ander mac adres op een netwerkkaart zetten gewoon een ondersteunde optie in de /etc/network/interfaces file. En anders is het ook triviaal te doen met het ip commando.
Mac adres spoofen is echt poepsimpel tegenwoordig. Dat is ook de reden dat een macfilter op je wifi zetten ook geen zin heeft. Het mac adres van gewhiteliste devices is zo gespoofed

[.oisyn]

Voordat je een MAC adres kan spoofen moet je wel eerst weten wat een valide MAC adres is voor een poort. Daarom suggereer ik de optie van een device dat je tussen een bestaande verbinding zet. Fire and forget.

[Beaves]

Klopt, je kan dat MAC adres weer achterhalen via bijvoorbeeld een wireshark trace, echter, de grootste uitdaging is het binnenkomen bij een Datacenter én de cage/kast van AMS-IX. Je moet daarvoor aangemeld worden (of op een whitelist staan) en je moet toestemming hebben om in de cage bij AMS-IX te komen.

Zomaar een pasje jatten werkt niet omdat voor zover ik weet alle datacenters een identificatie eisen middels een paspoort/ID/rijbewijs. En ja, die kan je ook vervalsen, maar dat vereist wel heel veel werk en social engineering etc.

[Subject117]

Was dit toevallig op poort 1900, had gisteren plots ook enorm veel traffic van broadcasting ( gelogged via mijn pfsense, en tegelijk ook 3 tal uurtjes nadien geen internet meer via Telenet ( belgische provider )

[Cybertinus994]

Ik denk dat dit arp broadcast verkeer is geweest. En anders iets wat nog lager in de stack zit. Dus niet tcp of udp naar een poort.
Verder zit Telenet ook niet aangesloten op de AMS-IX (bron: https://www.peeringdb.com/net/7692)

De kans dat jouw issues door deze AMS-IX problemen komen is dus verwaarloosbaar klein

[MazDaMan1970]

Ik acht die kans niet klein, aangezien de Russen zeker de capaciteit ervoor te hebben, om dit anoniem uit te voeren. Mis-configuratie is ook zeker niet ondenkbaar, maar ik acht die kans klein, aangezien men echt wel strenge procedures hiervoor zal hebben, om fouten te voorkomen.

[MarkieNL]

Zo kun je alles wel aan de Russen koppelen… NS storing afgelopen zondag?
Nee… lijkt mij iets wat overdreven.

[jaenster]

Ik denk dat het altijd verstandig is om er over na te denken dat het een mogelijkheid is. Het lijkt mij niet waarschijnlijk in zowel de NS hier bij de storing bij AMS-IX, maar dan nog is het verstandig om altijd alert te blijven dat dit kan zijn.

Overigens, het laat goed zien hoe wendbaar we zijn gezien heel veel sites via andere partners routeren bij gebrek aan AMS-IX (beter als ik had verwacht). Mocht dit een aanval zijn van rusland, en die van de NS ook, is die van de NS een stuk beter gelukt

[MazDaMan1970]

Is helemaal niet vreemd om de Russen hiervan te verdenken, aangezien dit vanuit militair oogpunt gezien redelijk makkelijke strategische doelwitten zijn om aan te vallen, bovendien kan dit redelijk anoniem uitgevoerd worden. Maar goed we zullen het waarschijnlijk nooit te weten komen...

[magic45]

Post je wel vaker dezelfde reactie in iets andere bewoordingen om je punt meer kracht bij te zetten?

[DrPoncho]

Zo kun je alles wel aan de Russen koppelen… NS storing afgelopen zondag?

I knew it!

[.oisyn]

Ik wilde net een reactie plaatsen op Tweakers, maar ik kreeg een foutmelding: "Je controletoken is ongeldig". De Russen zijn dus hier ook al actief!

Ik weiger een /s te plaatsen, maar ja, Poe's law...

[Reactie gewijzigd door .oisyn op 23 juli 2024 09:07]

[beerse]

Zo'n melding krijg ik in de regel als ik een tweakers pagina een uurtje open laat staan en daarna een reactie opstuur. Dat is redelijk standaard. Ergens tussen het ophalen van de pagina en het terug sturen van jou reactie is er een token vervallen.
Gelukkig zit de tweakers pagina zo in elkaar dat de reactie niet verloren gaat maar onder water het token wel word ververst. Daarmee kan je de reactie alsnog opsturen.

In dit geval zou het ook kunnen zijn dat je token is vervallen omdat onderweg tussen jou en tweakers de routering sterk is veranderd. Bijvoorbeeld als er is overgeschakeld van provider tussen wifi en mobiel-internet. Of in dit geval omdat het onderweg wordt omgeleid.

[.oisyn]

Wow, zelfs de referentie naar Poe's Law was niet genoeg...

[beerse]

Tja, ik kom nog wel eens in Irionië, daar bij de Sarcastische zee. Laten we zeggen dat Murphy weer eens gelijk heeft gehad.

[MazDaMan1970]

Zeker niet overdreven, aangezien men nog steeds niet weet wat de oorzaak was.

[kwakzalver]

(Aluhoedje op)
Zeer zeker is het verstandig hier naar te kijken en niet uit te sluiten.

Naar mijn bronnen zijn er binnen NL/BE/DE zijn er de afgelopen week diverse storingen geweest bij kritische systemen.
Storingen die normaliter niet voorkomen. Ad-hoc had ik er ook geen aandacht aan besteed en gedacht weer een bedrijfsfoutje...in de bezuiniging door het MT

Verstoring heb ik gesignaleerd bij ondermeer verkeersinfrastructuur, (tele-)communicatie, productielijnen.
Wat een indicatie is voor een gecoördineerde aktie.

Echter de mate van verstoring en ook dat sommige niet opgelost lijken te worden lijkt mij meer op een vingeroefening/test van de (geinjecteerde) tools. Een echte aanval lijkt het me nog niet....
(/Aluhoedje af)

[NoahAmber]

eerst waren het de gastarbeiders die overal de schuld van kregen, toen de surinamers/antillianen, toen de immigranten, de PvdA en een tijdje Halsema..en nu zijn de Russen aan de beurt...wie zou de volgende kunnen zijn?

[MazDaMan1970]

Jij haalt nu populistische zaken aan, dit is van een heel ander kaliber. Ik ben absoluut geen populist/complotdenker, maar ik vind dit allemaal net iets te toevallig. Wij weten van Rusland dat ze de capaciteit hebben om deze aanvallen (redelijk anoniem) te kunnen uitvoeren, dus dit is absoluut niet ondenkbaar!

[anpat]

Had op dat moment inderdaad problemen met onder andere aanloggen via ItsMe en onze site was tijdelijk niet bereikbaar.. en zo te zien op alle storingen was ik met itsme niet de enige... Goed dat het opgelost is.

[MikeyMan]

Merkte al dat de online meetings rond dat tijdstip aardig rommelig verliepen met mensen die er at random uitgegooid werden.

[wildhagen]

Ah, dat verklaart het. Ik kreeg opeens de melding in de browser dat bepaalde websites niet meer werkten, terwijl ik die kort ervoor nog had bezocht. Sommige anderen werkten wel, maar héél traag.

Ach, gelukkig niks ernstigs, en gelukkig ook weer lekker snel opgelost. Als dit het ergste is... overall gelukkig weinig problemen hiermee bij de AMS-IX.

[Petje!]

Hier waren ook issues merkbaar, vooral merkbaar bij het thuiswerken; VMware Horizon en Teams. Sessies waren langzaam en Horizon klapte er 1x uit.
Provider: T-Mobile