AMS-IX heeft storing en doet kwart van normaal verkeer - update

Internetknooppunt AMS-IX heeft een storing en handelt een kwart van het normale verkeer op het tijdstip af. Er lijken verder geen grote problemen te ontstaan.

De storing is volgens informatie uit de mailinglijst ontstaan om 19.08u. De terugval in verkeer is duidelijk te zien in de openbare stats van het internetknooppunt. Waar rond dat tijdstip verkeer van rond 10Tbit/s normaal is, gaat het nu om 2,5Tbit/s. De grafiek begint niet bij 0, waardoor het in de stats lijkt of er geen verkeer over het knooppunt meer gaat, maar dat is dus onjuist.

Sommige klanten hebben een korte dip waargenomen, zo meldt AMS-IX. "We zijn nu bezig met het verzamelen van gegevens voor het oplossen van problemen om onze leverancier te helpen de hoofdoorzaak zo snel mogelijk te achterhalen."

Update, donderdag: De storing was woensdagavond rond elf uur opgelost.

Storing AMS-IX 22 november 2023
Storing AMS-IX 22 november 2023

Door Arnoud Wokke

Redacteur Tweakers

22-11-2023 • 20:45

63

Submitter: agresionpower

Reacties (63)

63
62
29
3
0
23
Wijzig sortering
Zojuist een mailtje gekregen van de AMS-IX.

We are still further investigating into the issue, the initial finding is that all SLX switches in our platform have issues of flapping LACP interfaces.

We have opened a P1 ticket with our vendor for further troubleshooting, and will keep you updated

Edit: 23-11-2023 09:50 Het ziet er naar uit dat de storing weer terug is.

[Reactie gewijzigd door TheMetrotyranno op 23 juli 2024 07:39]

my guess: human error, zoals wel vaker met technologie op dit niveau als het zwaar fout loopt.
Dat is vaak het geval maar niet altijd. Evengoed is er iets stuk en gaan er gekke pakketjes alle kanten uit...
We kunnen nu dan wel gokken over de oorzaak, maar veel levert dat niet op. AMS-IX zal wel met een incident report komen. Dat is zeer waarschijnlijk nog interessant leesvoer ook :p
Voorlopig is afwachten het enige wat wij kunnen doen!

Mocht je de oplossing van wat dichterbij willen volgen; ze hebben intussen een informatie pagina: https://www.ams-ix.net/am...msterdam-peering-platform

Edit: volgens de informatiepagina is het probleem opgelost en was de oorzaak interactie tussen Extreme Networks (core) switches en de Juniper switches. Geen 'human error' dus!

[Reactie gewijzigd door the_stickie op 23 juli 2024 07:39]

de update die ze vandaag gaven dat er 1 customer port is geshut en de juniper core is geïsoleerd geeft enkel aan dat ze nog geen root cause hebben gevonden. Het feit dat ze die traffic als suspicious zagen sluit dat niet uit (en mogelijks zelfs opzet dus ook niet).
Uiteindelijk is het allemaal gemaakt door mensen dus alle fouten zullen human error zijn, behalve als er een boom op het gebouw is gevallen misschien.
Geen omgeving check doen of er mogelijk een boom een toekomstig gevaar kan opleveren is ook human error.
Alle problemen op aarde zijn per definitie menselijk. De "natuurlijke" wereld maakt geen problemen, alleen wij mensen ervaren dingen als een probleem (of erger, wij veroorzaken dus ook alle problemen).
Off-topic Recente studies tonen aan dat dieren veel bewuster en doelgerichter zijn dan we eerder aannamen.
Je kan imo ook zonder fout stellen dat een chimpansee die een stokje gebruikt om termieten uit een holletje te vissen een probleem heeft opgelost.
De chimpansee heeft het probleem opgelost, maar waarschijnlijk zag de chimpansee dit niet als een probleem. Als wij een schroef ergens in moeten draaien, dan pakken we een schroevendraaier. Dat wij gereedschap nodig hebben daarvoor ervaar je niet als een probleem. Het probleem ontstaat pas als er geen schroevendraaier aanwezig is. Neemt niet weg dat jouw eerste zin mij niets verbaast. :)
Of die aap dat als een probleem ziet of noemt (in zijn 'taal') is imo een semantische discussie. Feit is dat hij/zij de termieten zag en zich heeft moeten afvragen hoe die eruit te krijgen. Imo kan je dat zien als een probleemstelling. Net zoals 'Deze schroef zit vast, hoe maak ik deze schroef los' een (voor de meeste mensen eenvoudige) probleemstelling is.
Zo kun je overal wel problemen zien. Gelukkig heb ik een toetsenbord, anders kon ik niet hierop reageren.
Ook een human error....

1. Hadden ze daar niet naast de boom moeten bouwen
2. Hadden ze de boom niet naast het gebouw moeten planten.
Of hadden ze het gebouw voor kritische infra zo moeten bouwen dat er boom op kan vallen zonder problemen te geven.
Als die boom dan door mensen ooit geplant is?
23:51 Update
We have identified what seems to be the root cause and the platform is currently stable.

There was an issue related to interoperability between Juniper and Extreme, and more specifically with Juniper being too aggressive with RSVP messages.

We will be closely monitoring the platform while our customers re-enable their connections and traffic is returning on the platform.

Bron
wat zijn RSVP messages?
waren ze zichzelf aan het soort-van-DDOS'en?
RSVP is een protocol dat in een MPLS netwerk leeft. Routers spreken via dat protocol met elkaar af welk pad een bepaald soort traffic aflegt, en als er een router uitvalt dat het netwerk hier weet van heeft zodat er een ander pad afgesproken kan worden. https://www.juniper.net/d...ic-map/rsvp-overview.html

Er zal dus (als ik het goed begrijp) door een rsvp message tussen een Juniper en een Extreme router een path change zijn geweest waardoor er een kettingreactie ontstond van routers die niet met elkaar konden afspreken wat er is veranderd.
4ms hier naar google.com maar wel met uitschietertjes naar 6ms. Lijkt weer redelijk onder controle. En ik heb er zelf ook nog een 1 Gb/s switchje aan toegevoegd laatst, zal vast niet helpen...
In de monitoring hier zie ik een flink deel van de hosts nog steeds buiten de AMS-IX om gaan; latency die voor het begin van de storing op 4ms stabiel lagen zijn sinds gisterenavond tegen de 10ms. En dan niet alleen vanaf de centrale monitoring server maar ook onderling.

Verder zie je op dit moment het verkeer op de AMS-iX nog steeds significant lager dan gisterenochtend op dezelfde tijd. Er zal wel (terecht) de kat uit de boom gekeken worden voordat routeringen terug gaan...
Mooie reclame voor Juniper: nieuws: AMS-IX vervangt switches door Juniper en verlaagt energiegebruik met ...

De openbare stats kan je hier semi realtime volgen: https://stats.ams-ix.net/index.html
Het linkje in het artikel verwijst naar een static image |:(
Het hoeft natuurlijk niet iets van juniper te zijn. Ik heb Cisco switches down zien gaan omdat iemand de verkeerde configuratie had ingeladen...
Alles gaat down als je de verkeerde config in laadt…
Het issue ligt/lag niet bij de Junipers maar bij de Extremes.

edit: ah, toch wel wat complexer dan dat dus.

[Reactie gewijzigd door BHQ op 23 juli 2024 07:39]

https://www.ams-ix.net/am...msterdam-peering-platform
There was an issue related to interoperability between Juniper and Extreme, and more specifically with Juniper being too aggressive with RSVP messages.
Lijkt anders wel te liggen aan de (configuratie van de) Junipers.
Eerder bij de interactie...
There was an issue related to interoperability between Juniper and Extreme, and more specifically with Juniper being too aggressive with RSVP messages.
Bron
Het energieverbruik gaat met 85% naar beneden en de performance maar met 75%. Bottom line is dat een winst, toch? :-p

Neen, even serieus, die 85% is wel netjes (was running verbruik van 52.800W naar nu 8.200W terwijl de switches ook beter voorbereid zijn op de toekomst), maar het komt inderdaad niet zo goed over nu...
Dank je. Interessant om te zien dat de fout ontstaat bij max traffic.
Er is een doosje die dit in combinatie met de rsvp niet meer aankan.

Ook interessant dat de traffic nu beduidend lager is. Er wordt door derden of amsix anders gerouteerd.
Dat zou vreemd zijn als het issue dan 3.5 maanden niet voorkomt en dan opeens bij allemaal.

Wat het issue exact is lijkt me erg vroeg om te roepen, want zelfs de eerdere quotes/berichten op de AMS-IX site staan er niet meer op. Maar als ik zo tussen de regels door lees lijkt het een gevalletje van A werkt, B werkt, maar A+B werkt niet...
Ik vraag me dan toch wel af waar die 7.5Tb/s normaal vandaan komt die blijkbaar niet voor zoveel problemen zorgt als hij wegvalt.
Het verkeer 'verdwijnt' niet. ISP's hebben meerdere peering / transit verbindingen. Het verkeer neemt simpel gesproken een andere route.
Ja, dat. En dan is er bijvoorbeeld ook nog NL-IX (KPN en co). Plus directe peering tussen transit providers, POPs/MeetMe rooms, etc.
Libert Global heeft volgens mij ook nog een eigen IX via hun eigen backbone.
Je ziet op hetzelfde moment het verkeer op bijv de NL-IX omhoog klappen.

Zelf merkte ik veel kortstondig wegvallende verbindingen, meeste is redelijk snel weer hersteld via andere transits

[Reactie gewijzigd door Calypso op 23 juli 2024 07:39]

Zou denken einde van de dag en veel bedrijven doen backuppen? Veel mensen komen rond dat tijd stip thuis en gaan tv cq streams kijken (weet het niet hoor)
Het is primetime; dus TV/streams, gaming, web, etc. Backups worden in de regel 's nachts gemaakt bij de meeste partijen - plus gaat dat lang niet altijd over AMS-IX.
Wellicht gaat ook Xbox game streaming via AMS-IX? Ik kan me iig niet herinneren dat ik ooit heb moeten wachten op beschikbare stream en wacht nu al 15 minuten op starfield stream. Ff testen voor installatie dacht ik.
Dat zou prima kunnen. Normaliter zou dat verkeer dan wel een andere weg moeten kiezen - maar ik weert niet hoe de Xbox infrastructuur verbonden is en met welke partijen ze peeren. Ik verwacht wel dat een partij als Xbox z'n zaakjes goed op orde heeft en bijvoorbeeld ook een direct connect met NL-IX (KPN en co).
Voor content weet ik dat dit wel zo is bij kpn, maar streaming van Xbox games zal toch via serverpark van ms moeten gaan. Kan me voorstellen dat Xbox park directe lijn met amsix heeft.
En latency neemt gewoon toe.

Normaal 5ms is met de helft nu 10ms.
Holy shit - inderdaad. Naar Google en Cloudflare zit ik op de gewone 3ms, naar Azure is dat nu 23ms (normaliter 3-4ms). Dat is wel een bizarre toename - op een dedicated (1:1) glasverbinding.Op een WBA lijntje (KPN NetwerkNL) zijn ze nu alle drie op 4ms.

Update: en op een Ziggo lijntje doen die drie nu ~ 15ms, wat vrij normaal is op die locatie.

[Reactie gewijzigd door jurroen op 23 juli 2024 07:39]

dus er kan nu 4x zoveel data door de lijn ,

Dat is een kromme zin maar aangezien de zelfde data er langer over doet. heb je na die 24 ms dus toch de zelfde hoeveelheid data verstuurd.

throughput is niet alleen data per sec maar ook queue time en total time is een gedeelte als je kijkt naar hoeveel data er echt verwerkt wordt.

Dus het s niet zo dat die data weg is en een gedeelte zal ook via unicast herverdeelt worden via andere routes of waarders op de BGP routes als het goed is .
Vroeger lag bij een AMS-IX storing het halve land plat. Nu gaat alles vrijwel naadloos over naar o.a NL-IX. Mooi om te zien!
Dit ligt ook zeker aan het soort probleem en hoe het fout gaat, maar er is denk ik wel degelijk geleerd van de vorige keer met voldoende capaciteit beschikbaar hebben op je andere links/transits.

Recentelijk hebben we ook vaker incidenten gehad bij een andere IX, waarbij we wel de route servers konden benaderen - maar niet alle verbonden partijen. Dit heeft als resultaat dat je denkt dat je dus iemand gewoon kan bereiken, maar in het echt niet het geval is.

Nu las ik dat BGP sessies gingen flappen, wat je echt wel door hebt als het over een grote IX gaat als AMS-IX :-).
Dat vrijwel naadloos viel erg tegen. Gedurende ruim een uur zag ik verbindingen op en neer gaan. Volgens mij is daarop bij de betreffende providers of bij de AMS-IX actie ondernomen om dat te voorkomen.
Probleem lag hem vooral dat AMS-IX niet volledig plat was maar vooral veel packtloss gaf (althans voor ons). We moesten plat gezegd onze port handmatig uitzetten om verkeer niet meer richting AMS-IX te sturen. Kan me voorstellen dat andere providers hetzelfde probleem hadden.

[Reactie gewijzigd door jordynegen11 op 23 juli 2024 07:39]

Ja, ik zag ook dat soort gedrag - mijn opmerking was vooral op het "naadloos" gedrag: dat ligt voor een groot deel aan de aard van de storing en de manier waarop de gekoppelde partij(en) reageren. Volgens mij zijn er veel partijen die na een schakeling het zekere voor het onzekere nemen en een bepaalde tijd even (in dit geval) de AMS-IX links laten liggen. Daarom zag je ook het verkeer nog niet terugkomen op het normale niveau en was de impact van de storing zojuist ook veel minder.
Inderdaad. Daarom zijn veel paniek berichten als dit en dat kan niet want wat als internet er uit ligt. Nou, dan gaat het een keertje fout, en daar leren we van en maken we het weer robuuster.
Het lijkt erop dat ze vandaag weer een storing hebben...
Jep, sinds 09:40 weer verschillende verbroken peerings en klapperende connecties.
Huidige intake met 1.7tbit/s zit ook ver onder het gemiddelde.

https://stats.ams-ix.net/index.html

[Reactie gewijzigd door lolsra op 23 juli 2024 07:39]

Huidige verkeer neemt weer met rap tempo toe. Momenteel alweer 4.1 Tb/s. Verwacht dat het snel allemaal zal herstellen.
Dat verklaard dus dat mijn monitoring af en toe verbinding verliest, en ping sinds 19:08 8ms hoger, met in de tranisitie veel pakketloss.

https://tweakers.net/i/Pd...BgoTTtlm.png?f=user_large

[Reactie gewijzigd door KingHorse op 23 juli 2024 07:39]

Als het inderdaad flapping LACP tussen SLX betreft is dit al eerder bekend (2020) toen destijds niet opgelost volgens artikel (reload)

https://extreme-networks....rticleDetail?an=000057743
Het is kennelijk een ander issue, wat wel LACP flaps veroorzaakt.
Gaan we weer.. Ze hebben weer een drop nu. Van 7 naar 2Tbit.

[Reactie gewijzigd door jordynegen11 op 23 juli 2024 07:39]

Ja, mijn monitoring zowel Zabbix als Smokeping laten dezelfde dingen zien als gisterenavond. Blijkbaar is de backup verbinding niet 100% stabiel naar Hetzner toe. (Vanaf Tweak)
Ah vandaar dat YT vandaag wat moeite had om de buffer vol te houden? Begon ergens in de middag al.

Op dit item kan niet meer gereageerd worden.