PDA

Bekijk Volledige Versie : AMS-IX down?



Domenico
13/05/15, 13:34
Iemand meer info?

SF-Jeroen
13/05/15, 13:37
Wij zien ook enorme loss naar sommige providers, dus zou goed kunnen

Ahmed
13/05/15, 13:38
Verschillende netwerken zijn/waren hier (even) onbereikbaar. Apart zeg.

Kevin Bentlage
13/05/15, 13:39
Ok hier flinke outages, ook op kantoor zelf ligt de verbinding eruit.


Sent from my iPhone using webhostingtalk mobile app

Solutionsource
13/05/15, 13:42
Ook hier problemen. Vanuit DataWeb netwerk geen probleem naar ons eigen netwerk (Leasweb), maar wel naar diverse andere grote sites (google, tweakers, twitter, nu.nl, etc...)

Stewie
13/05/15, 13:47
We hebben direct alles gereroute (automatisch) naar de tier 1 transits. Het probleem is dat alle ISPs dat ook doen, en dat enkele minuten kan duren bij routers die (zeer) veel verkeer afwikkelen (denk een UPC, Ziggo, etc).

Skredd
13/05/15, 13:48
NLIX lijkt ook last te hebben https://www.nl-ix.net/network/traffic/

Solutionsource
13/05/15, 13:48
Stewie. Je reroute naar je transits. Klopt het dan inderdaad dat die packet-loss ontstaat op AMS-IX?

pannenkoek
13/05/15, 13:51
https://pbs.twimg.com/media/CE4V6XXWoAAX4_l.png:large

2 Tbps aan traffic effe weg

Stewie
13/05/15, 13:52
Stewie. Je reroute naar je transits. Klopt het dan inderdaad dat die packet-loss ontstaat op AMS-IX?

Als de AMS-IX wegvalt dan rerouten we direct naar de nieuwe beste routes. De packet loss ontstaat omdat onze routers, maar ook die van de ISPs zoals Ziggo en UPC, deze nieuwe routes moeten leren. Dat kost CPU kracht. Omdat het halve internet in Nederland over de AMS-IX gaat moeten die routers enorm veel nieuwe routes leren, en dus gaan ze even (tijdelijk) over de kop. Dan krijg je packet loss.

Solutionsource
13/05/15, 13:54
Stewie, thanks. Dat rerouten packet-loss veroorzaakt is helder. Het was mij (op het moment van schrijven) nog niet duidelijk dat het probleem werkelijk bij AMS-IX zat.
Traffic-grafiekjes van Pannenkoek en die op tweakers.net (AMS-IX zelf is voor mij onbereikbaar) spreken boekdelen.

Nog opvallend dat de "schade" niet groter is. Dat is een hele lading traffic die opeens over andere verbindingen moet.

Ahmed
13/05/15, 13:54
Ben benieuwd wat er gebeurd is. Niemand hier toevallig gestruikeld over een aantal kabels? Misschien een nieuwe stagiair bij AMS-IX?

Stewie
13/05/15, 13:55
NLIX lijkt ook last te hebben https://www.nl-ix.net/network/traffic/

Waarschijnlijk heeft NLIX geen problemen, maar wat je ziet is het verkeer dat NLIX bij AMSIX wegzet dat nu wegvalt.

Skredd
13/05/15, 13:56
Waarschijnlijk heeft NLIX geen problemen, maar wat je ziet is het verkeer dat NLIX bij AMSIX wegzet dat nu wegvalt.

Makes sense inderdaad

Boskoop
13/05/15, 14:02
Waarschijnlijk heeft NLIX geen problemen, maar wat je ziet is het verkeer dat NLIX bij AMSIX wegzet dat nu wegvalt.

dit idd, hetzelfde zie je bij openpeering gebeuren:
12233

Boskoop
13/05/15, 14:07
dipje in beeld
12234

Powermage
13/05/15, 14:07
Je ziet dat niet gebeuren toch, correct me if im wrong hoor, maar je ziet bij NL-IX en OpenPeering een dip onstaan die weer terug komt.
Dus niet een dip omdat alles weer over de amsix gaat, maar eerder de routers die overbelast zijn door de grote aantal bgp routes aanpassingen waardoor ze helemaal geen verkeer doorzetten.

mgerritsen
13/05/15, 14:22
Alles was hier ook inderdaad even plat, schrok eerst even dat het eigen servers waren maar al gauw kwam ik tot de conclusie dat het de AMS-IX was. Wel ziek, dat het uiteindelijk toch wel ruim een kwartier duurde voordat grotendeels alles weer functioneerde. Wat een afhankelijkheid dan eigenlijk van één knooppunt zeg:O

Smashmint
13/05/15, 14:37
Ik zag het volgende voorbij komen:



Today Wednesday 13/05/2015 at 12:20 UTC+2 an installation engineer working on the PE under maintenance in EQUINIX AM3, while testing one of the newly installed 100GE modules, accidentally placed a loop on the ISP peering VLAN.

DETAILS:

The loop caused a high CPU on all backbone and customer modules resulting in many BGP sessions dropping.
The incident lasted 10 minutes.
BGP sessions are restoring.

Kevin Bentlage
13/05/15, 14:44
Ik zag het volgende voorbij komen:

Oeps... Foutje...

Kevin Bentlage
13/05/15, 14:53
-nvm-

mgerritsen
13/05/15, 15:00
Direct populairste man in Nederland haha. Wel apart dat ze nieuwe interfaces eerst testen op een productie VLAN en niet in een test omgeving, indien mogelijk. Zo zie je maar, foutje zit in een klein hoekje:P

drex
13/05/15, 16:00
Foutje bedankt!

Rik
13/05/15, 22:17
Ook weer iets dat eigenlijk gewoon niet voor moet kunnen komen. Falen in de (blijkbaar schijn-)redundantie.

Paulewk
14/05/15, 14:51
Ook weer iets dat eigenlijk gewoon niet voor moet kunnen komen. Falen in de (blijkbaar schijn-)redundantie.

Er is helemaal geen schijn redundantie. AMS-IX is hardstikke redundant, alleen als mensen configfouten maken heb je niets aan die redundantie. Waar mensen werken worden fouten gemaakt.

Mgerritsen, Als je een nieuwe AMS-IX poort afneemt word die altijd eerst in een quarantaine vlan geplaatst, niet in productie dus. Zal hier dus gewoon echt ergens een fout gemaakt zijn.

systemdeveloper
14/05/15, 15:31
Dus als je geen 2de persoon hebt die de eerste controleert of ie het goed gedaan heeft... dan heb je dus geen redundantie :)

dennis0162
14/05/15, 15:58
Ach van die lullige foutjes maakt iedereen wel eens.
Alleen dit heeft een vrij grote impact omdat ineens alles om gerouteerd/herberekend moet worden.

visser
14/05/15, 16:32
Ook weer iets dat eigenlijk gewoon niet voor moet kunnen komen. Falen in de (blijkbaar schijn-)redundantie.

Ik ken van die managers die ook denken dat ze er wat snappen door bij een storing te roepen "het moet redundant".
De storingen die uiteindelijk merkbaar worden liggen niet zo vaak aan een gebrek aan redundantie.

drex
14/05/15, 20:56
Dus "gewoon" menselijk falen....

Rik
15/05/15, 00:48
Er is helemaal geen schijn redundantie. AMS-IX is hardstikke redundant, alleen als mensen configfouten maken heb je niets aan die redundantie. Waar mensen werken worden fouten gemaakt.

Mgerritsen, Als je een nieuwe AMS-IX poort afneemt word die altijd eerst in een quarantaine vlan geplaatst, niet in productie dus. Zal hier dus gewoon echt ergens een fout gemaakt zijn.

Daarom dien je het risico op 'human-errors' ook uit te sluiten, of het geheel dusdanig in te richten dat een human-error geen effect kan hebben. Dit is altijd zo'n slecht excuus.