IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Actualités Discussion :

Google provoque accidentellement une panne massive d'Internet au Japon

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 458
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 458
    Points : 197 853
    Points
    197 853
    Par défaut Google provoque accidentellement une panne massive d'Internet au Japon
    Google provoque accidentellement une panne massive d'Internet au Japon,
    qui a duré des heures bien que l'erreur ait été corrigée après 8 minutes

    Lorsqu’une entreprise de l’envergure de Google commet une petite erreur, cela peut avoir de grandes répercussions comme l’illustre cet épisode japonais.

    Vendredi, vers midi (heure du Japon), une partie du pays a connu une perturbation dans sa connexion Internet (parmi les victimes, certains ont éprouvé des difficultés à se connecter et d’autres n’avaient tout simplement plus accès à Internet).

    La cause ? Google a accidentellement fait planter un BGP suite à une erreur de configuration qui a provoqué de faux préfixes de pairs annoncés envoyés à Verizon. Cela a eu pour effet que les fournisseurs d'Internet tels que NTT Communications et KDDI Corp. ont été laissés sans connexion Internet, les plus chanceux de leurs clients ont indiqué qu’ils avaient des difficultés à naviguer sur Internet, tellement la connexion était lente.

    Le service Internet de NTT, appelé OCN, est utilisé par près de 7,7 millions d'utilisateurs domestiques et 480 000 entreprises et est le plus important au Japon.

    Pour rappel, le Border Gateway Protocol (BGP) est un protocole d'échange de route utilisé notamment sur le réseau Internet. Son objectif est d'échanger des informations de routage et d'accessibilité de réseaux (appelés préfixes) entre Autonomous Systems (AS).

    Google a reconnu son erreur dans un communiqué publié aux médias japonais, expliquant qu'il a corrigé la mauvaise configuration en seulement 8 minutes. En revanche, la panne a duré plusieurs heures. Le porte-parole de la firme Asahi Shimbun s’est excusé pour les désagréments et l’anxiété provoqués. Le porte-parole a ajouté que la société s'efforcera de prévenir une telle panne à nouveau. Google n'a pas précisé si l'erreur était humaine ou si elle provenait d’un dysfonctionnement technique.

    Il va sans dire que la panne a affecté plusieurs entreprises et services, y compris des poids lourds comme la plateforme de marché aux puces Mercari ou l’application de communication Line. L’entreprise de chemin de fer East Japan Railway, les banques Resona Bank, Kinki Osaka Bank, et d'autres groupes ont également subi les conséquences de cette erreur. Face à cette panne massive, le Ministère des Affaires internes et de la Communication a même ouvert une enquête pour déterminer les causes exactes de l’incident.

    Selon les conclusions apportées par BGP Mon, un outil de nouvelle génération qui surveille les informations de routage BGP en temps réel, Google est accidentellement devenu un fournisseur de transition pour Jastel.

    L’opérateur a tenté d’envoyer le trafic pour ce réseau par le biais de Google. Or, Google ne propose pas de services de transition. De fait, le trafic de réseaux tiers ne doit jamais passer par son système, sous peine de provoquer de telles conséquences.

    « Si nous examinons de plus près les chemins AS impliqués à partir du côté droit, nous voyons que le préfixe a été annoncé par 45629 (Jastel) comme prévu. Puisque Jastel s’apparie à Google (15169), c'est la prochaine AS que nous voyons. L'AS suivant dans le chemin d'accès est 701 (Verizon) et c'est là que cela devient intéressant, car Verizon a commencé à fournir un transit pour Jastel via Google. Verizon (701) l’a ensuite annoncé à plusieurs de ses clients, dont certains sont très importants tels que KPN (286) et Orange (5511). Donc, en regardant maintenant 4 exemples de chemins, nous pouvons le voir frapper de grands réseaux en Europe, en Amérique latine, aux États-Unis et en Inde (9498 Airtel).

    « Dans l'exemple ci-dessus, nous pouvons voir comment Google est accidentellement devenu un fournisseur de transition pour Jastel en annonçant des préfixes pairs à Verizon. Étant donné que Verizon choisirait ce chemin vers Jastel, il aurait envoyé du trafic pour ce réseau vers Google. Non seulement cela s'est produit pour Jastel, mais aussi des milliers d'autres réseaux.

    « Google n'est pas un fournisseur de transit et le trafic pour les réseaux tiers ne devrait jamais passer par le réseau Google. Jastel a quelques fournisseurs en amont et avec l'ajout de Google et Verizon sur le chemin, il est probable que seuls les clients de Verizon (ce qui est encore important) auraient choisi ce chemin et seuls ceux qui n'avaient pas d'autre alternative ou préféraient spécifiquement Verizon sur des chemins plus courts », explique BGP Mon.

    En clair, la raison de ce dysfonctionnement est que Google n’est pas un fournisseur de transit, ce qui signifie que le trafic pour les réseaux tiers ne devrait jamais passer par son système.

    « Il est facile de commettre des erreurs de configuration qui peuvent mener à des incidents comme celui-ci », a estimé BGP Mon. « Dans ce cas, il apparaît qu'une erreur de configuration ou un problème de logiciel dans le réseau de Google a permis d'annoncer par inadvertance des milliers de préfixes à Verizon, ce qui a propagé la fuite à plusieurs de ses concurrents. »

    Source : conclusion de l'enquête BGP Mon, Japan Times, Asashi
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    Homme Profil pro
    retraité
    Inscrit en
    Avril 2009
    Messages
    374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 91
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : retraité
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Avril 2009
    Messages : 374
    Points : 783
    Points
    783
    Par défaut Les processus Internet ne sont pas fiables
    Il faudrait revenir (entre autres) à d'autres conception de routeurs aux paramétrages moins hasardeux.
    En fait il faudrait au moins deux réseaux physiques, l'un de transport, l'autre de commandes, absolument indépendants et même un troisième pour supervision. Ne rêvons pas !
    Faire n'importe quoi avec n'importe qui, je ne dirais pas (ecore) n'importe comment, n'en sommes-nous pas là en ce moment.

Discussions similaires

  1. Réponses: 1
    Dernier message: 19/08/2011, 16h53
  2. Provoquer volontairement une panne sous Windows 7
    Par agenceaupair dans le forum Windows 7
    Réponses: 13
    Dernier message: 26/06/2010, 15h28
  3. programmer en C++ une barre d'outils Internet
    Par panda31 dans le forum C++
    Réponses: 2
    Dernier message: 26/09/2005, 14h19
  4. [Oracle / Admin] Simuler une panne
    Par shaun_the_sheep dans le forum Administration
    Réponses: 12
    Dernier message: 04/11/2004, 15h13
  5. Connexion à une base SQL_Serve via Internet
    Par Yoann_D dans le forum MS SQL Server
    Réponses: 5
    Dernier message: 22/07/2003, 15h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo