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 54PARTAGES 16 1 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 : Japan Times, Asashi 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 Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 1 commentaire Poster une réponse Signaler un problème Membre averti https://www.developpez.com

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.

2 0 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.

