Les pannes de telephone du week end
Dernière réponse : dans Le Bistrot
Dire que je croyais que ca venait des telephones de chez moi, il semblerait que ce soit simplement les centrales de FT du nord et de l'ouest qui sont en carafe ![[:le kneu] [:le kneu]]()
Quelqu'un aurait des infos sur le sujet ?
Perso quand on m'appelle dans 2appels sur 3 la personne a l'autre bout du fil m'entend pas, sinon quand je decroche, tres souvent j'ai pas de tonalité. Dans le meme genre le 1013 est soit disant surchargé et le 1014 est soit disant pas attribué![[:kazouille] [:kazouille]]()
D'apres le journal c'est sensé etre fini depuis dimanche 22H, FT aurait il acheté les medias ?
l'invasion commence
![[:le kneu] [:le kneu]](http://m.bestofmedia.com/sfp/design/usr/fr/smilies/c7/fd/le-kneu.gif)
Quelqu'un aurait des infos sur le sujet ?
Perso quand on m'appelle dans 2appels sur 3 la personne a l'autre bout du fil m'entend pas, sinon quand je decroche, tres souvent j'ai pas de tonalité. Dans le meme genre le 1013 est soit disant surchargé et le 1014 est soit disant pas attribué
![[:kazouille] [:kazouille]](http://m.bestofmedia.com/sfp/design/usr/fr/smilies/0e/85/kazouille.gif)
D'apres le journal c'est sensé etre fini depuis dimanche 22H, FT aurait il acheté les medias ?
l'invasion commence
Autres pages sur : pannes telephone week end
FLo14 a écritC'est pas le même mode de connexion.
mais ca viendrait de quoi alors ???
dans le journal on a eu le droit aux classiques virus mais ils pretendent que cette fois ca viendrait de signaux bizarres recu depuis d'autres terminaux a l'etranger, un langage different qui aurait bloqué les machines
NiahBoumPof is back a écritmais ca viendrait de quoi alors ???
dans le journal on a eu le droit aux classiques virus mais ils pretendent que cette fois ca viendrait de signaux bizarres recu depuis d'autres terminaux a l'etranger, un langage different qui aurait bloqué les machines
dans le journal on a eu le droit aux classiques virus mais ils pretendent que cette fois ca viendrait de signaux bizarres recu depuis d'autres terminaux a l'etranger, un langage different qui aurait bloqué les machines
Aux dernières nouvelles, c'est un bug du software
vu au JT de 20h de TF1 : le bug viendrait d'un equipement informatique sur un commutateur de la region de Reims, qui aurait recu des appels mal formatés, peut etre d'origine VoIP
Et donc le commutateur serait passé en mode securité en reduisant l'ecoulement du traffic...
Mais rien sur un reseau alternatif pour la gestion du 15
Et donc le commutateur serait passé en mode securité en reduisant l'ecoulement du traffic...
Mais rien sur un reseau alternatif pour la gestion du 15
Le réseau de FT saturé à cause de "zéros parasites" dans sa passerelle VoIP
Par Christophe Guillemin
ZDNet France
Mercredi 3 novembre 2004
Les problèmes d'appels téléphoniques constatés le week-end dernier sur le réseau de l’opérateur sont dus à un bug dans la plate-forme qui assure les services de voix sur IP (VoIP). France Télécom a remédié au problème.
France Télécom a clairement identifié l'origine des dysfonctionnements survenus ce week-end sur son réseau téléphonique et qui ont perturbé plusieurs milliers d’appels. L'opérateur a mis en cause sa passerelle unique, située à Reims, qui gère ses services de téléphonie sur réseau internet, ou voix sur IP (VoIP).
Le bug provient d'«une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP», a indiqué FT mardi soir dans un communiqué. En fait, a précisé l'un de ses porte-parole à ZDNet, cette passerelle, qui fait transiter les appels en VoIP vers le réseau commuté classique, a «mal interprété» certains numéros composés par des utilisateurs. Explication plus poussée: un simple zéro a été ajouté par erreur, sans que l'utilisateur le sache. Résultat, les numéros composés ont été considérés à tort comme provenant d’un opérateur tiers international.
26 commutateurs sur 600 saturés
Cette anomalie a été détectée par 26 commutateurs téléphoniques (sur un total de plus de 600 en France métropolitaine) qui tentaient sans succès d'acheminer les numéros mal formatés. Situés notamment à Paris, Marseille, Strasbourg, Tours et Caen, ces commutateurs se sont alors mis en mode d'"auto-protection". Un mécanisme qui les conduit à garder en mémoire les numéros mal composés. Mais le week-end dernier, cette mémoire a rapidement été saturée car les utilisateurs ont bien entendu renouvelé les appels qui n'aboutissaient pas. Par un effet "boule de neige", le trafic a été ralenti. Ce phénomène s'apparente, dans le monde informatique, à un dépassement de mémoire tampon, ou buffer overflow.
France Télécom a dû réinitialiser et mettre à jour ses commutateurs. Le bug relatif aux "zéros parasites" a quant à lui été corrigé en installant un patch au niveau de la passerelle VoIP de Reims, explique notre interlocuteur chez FT.
Au final, l'opérateur assure que seulement «quelques milliers d’appels» n'ont pas été correctement acheminés du premier coup, sur un total de 61,9 millions passés samedi et dimanche.
«C'est souvent lorsqu'une nouvelle technologie sort des laboratoires et est implantée dans des conditions réelles que l'on s'aperçoit des bugs», s'est justifié le porte-parole à ZDNet.
Des partenaires de FT également concernés?
France Télécom n'est peut-être pas le seul en cause. Mais l'entreprise s'est refusée à communiquer le nom de ses fournisseurs de services VoIP concernés par ces dysfonctionnements. «C'est nous qui avons la responsabilité de gérer notre réseau», se borne à préciser le porte-parole.
Contactée par ZDNet, la société française Netcentrex, l'un des principaux partenaires de FT dans ce domaine, n'a pas souhaité s'étendre sur la question. «Nous ne souhaitons faire aucun commentaire sur les interruptions de services de France Télécom», explique-t-elle dans une déclaration écrite reçue mercredi matin, «et laissons le soin à France Télécom de présenter les résultats de ses investigations sur la chaîne complexe d'événements à l'origine du problème».
En guise d'excuses, l'opérateur historique a décidé de ne pas facturer «à l'ensemble de ses clients» la totalité des communications nationales, locales ou longue distance, passées sur son réseau fixe entre samedi 16h00 et dimanche 21h00.
France Télécom a lancé ses offres résidentielles de VoIP en juin dernier, environ six mois après celles destinées aux entreprises.
source : http://www.zdnet.fr/actualites/technologie/0,39020809,3...
Par Christophe Guillemin
ZDNet France
Mercredi 3 novembre 2004
Les problèmes d'appels téléphoniques constatés le week-end dernier sur le réseau de l’opérateur sont dus à un bug dans la plate-forme qui assure les services de voix sur IP (VoIP). France Télécom a remédié au problème.
France Télécom a clairement identifié l'origine des dysfonctionnements survenus ce week-end sur son réseau téléphonique et qui ont perturbé plusieurs milliers d’appels. L'opérateur a mis en cause sa passerelle unique, située à Reims, qui gère ses services de téléphonie sur réseau internet, ou voix sur IP (VoIP).
Le bug provient d'«une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP», a indiqué FT mardi soir dans un communiqué. En fait, a précisé l'un de ses porte-parole à ZDNet, cette passerelle, qui fait transiter les appels en VoIP vers le réseau commuté classique, a «mal interprété» certains numéros composés par des utilisateurs. Explication plus poussée: un simple zéro a été ajouté par erreur, sans que l'utilisateur le sache. Résultat, les numéros composés ont été considérés à tort comme provenant d’un opérateur tiers international.
26 commutateurs sur 600 saturés
Cette anomalie a été détectée par 26 commutateurs téléphoniques (sur un total de plus de 600 en France métropolitaine) qui tentaient sans succès d'acheminer les numéros mal formatés. Situés notamment à Paris, Marseille, Strasbourg, Tours et Caen, ces commutateurs se sont alors mis en mode d'"auto-protection". Un mécanisme qui les conduit à garder en mémoire les numéros mal composés. Mais le week-end dernier, cette mémoire a rapidement été saturée car les utilisateurs ont bien entendu renouvelé les appels qui n'aboutissaient pas. Par un effet "boule de neige", le trafic a été ralenti. Ce phénomène s'apparente, dans le monde informatique, à un dépassement de mémoire tampon, ou buffer overflow.
France Télécom a dû réinitialiser et mettre à jour ses commutateurs. Le bug relatif aux "zéros parasites" a quant à lui été corrigé en installant un patch au niveau de la passerelle VoIP de Reims, explique notre interlocuteur chez FT.
Au final, l'opérateur assure que seulement «quelques milliers d’appels» n'ont pas été correctement acheminés du premier coup, sur un total de 61,9 millions passés samedi et dimanche.
«C'est souvent lorsqu'une nouvelle technologie sort des laboratoires et est implantée dans des conditions réelles que l'on s'aperçoit des bugs», s'est justifié le porte-parole à ZDNet.
Des partenaires de FT également concernés?
France Télécom n'est peut-être pas le seul en cause. Mais l'entreprise s'est refusée à communiquer le nom de ses fournisseurs de services VoIP concernés par ces dysfonctionnements. «C'est nous qui avons la responsabilité de gérer notre réseau», se borne à préciser le porte-parole.
Contactée par ZDNet, la société française Netcentrex, l'un des principaux partenaires de FT dans ce domaine, n'a pas souhaité s'étendre sur la question. «Nous ne souhaitons faire aucun commentaire sur les interruptions de services de France Télécom», explique-t-elle dans une déclaration écrite reçue mercredi matin, «et laissons le soin à France Télécom de présenter les résultats de ses investigations sur la chaîne complexe d'événements à l'origine du problème».
En guise d'excuses, l'opérateur historique a décidé de ne pas facturer «à l'ensemble de ses clients» la totalité des communications nationales, locales ou longue distance, passées sur son réseau fixe entre samedi 16h00 et dimanche 21h00.
France Télécom a lancé ses offres résidentielles de VoIP en juin dernier, environ six mois après celles destinées aux entreprises.
source : http://www.zdnet.fr/actualites/technologie/0,39020809,3...
Le communiqué officiel de FT :
Ralentissement dans l'acheminement d'une partie du trafic téléphonique pendant le week-end des 30/31 octobre
Paris, le 2 novembre 2004
Conclusions de l’enquête diligentée par le Président de France Télécom
Les conclusions de l’enquête commanditée par le Président de France Télécom lui ont été présentées aujourd’hui à 15 heures.
Le ralentissement de l’acheminement du trafic téléphonique au cours de l’après-midi du samedi 30 octobre et du dimanche 31 octobre a perturbé quelques milliers d’appels sur un total de près de 62 millions de communications écoulées pendant ces deux jours.
La cause du ralentissement de l’écoulement du trafic est désormais clairement identifiée.
Elle réside dans une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP situé à Reims. Cette anomalie logicielle a provoqué une anormalité dans le formatage de la numérotation de certains appels. Ces anormalités ont déclenché les protections de sécurité de vingt-six commutateurs (sur un total de plus de 600) pour éviter une panne du réseau.
Le déclenchement de ces protections a eu pour effet de ralentir momentanément l’écoulement du trafic de ces commutateurs réduisant de moins de 1% l’efficacité des appels émis.
La mobilisation des équipes techniques de France Télécom durant tout le week-end a permis de limiter l’ampleur et la durée de ce dysfonctionnement et d’éviter une contamination du réseau.
France Télécom rappelle que l’ensemble du réseau et de ses commutateurs fonctionne normalement depuis dimanche soir.
France Télécom présente toutes ses excuses à chacun de ceux qui ont subi les effets de cette perturbation.
France Télécom a décidé de ne pas facturer à ses clients les communications nationales locales et longue distance passés sur son réseau fixe entre samedi 30 octobre 2004 à 16 heures et dimanche 31 octobre 2004 à 21 heures.
ANNEXE
Dès les premières heures de l’incident, le Président Thierry Breton, qui a coordonné l’ensemble des opérations de retour à la normale a ordonné une enquête précise pour établir la chronologie des faits, déterminer les causes de la perturbation des 30 et 31 octobre 2004 sur certains commutateurs de France Télécom et mettre en œuvre les remèdes appropriés.
Chronologie des faits
Samedi 18h. France Télécom constate un dysfonctionnement dans l’écoulement d’une partie du trafic téléphonique fixe à l’arrivée, les perturbations empêchant de joindre, ponctuellement (et de façon non répétitive) dans certains secteurs géographiques, leurs correspondants.
Vingt-six commutateurs sur un total de 600 centraux de France Télécom sont affectés mais jamais plus de dix d’entre eux ne le sont simultanément.
Une cellule nationale de France Télécom est mobilisée sous l’autorité directe de son Président. Sur le terrain, les techniciens de France Télécom engagent les travaux permettant le retour à la normale par la mise en œuvre d’une procédure de réinitialisation des commutateurs concernés.
Dimanche midi. France Télécom développe une solution logicielle et lance dans une logique de précaution, une procédure préventive sur l’ensemble des commutateurs en service sur le territoire national.
Dimanche après midi. France Télécom annonce que huit commutateurs restent défaillants. En étroite concertation avec les pouvoirs publics, France Télécom communique sur la procédure à suivre en cas de non acheminement d’un appel vers un service d’urgence au cas où la perturbation se reproduirait.
Dimanche 21h. Retour à la normale. Selon la procédure de précaution définie, un patch logiciel a été appliqué sur l’ensemble des commutateurs.
Points saillants.
La perturbation a concerné un ou plusieurs commutateurs situés dans les villes suivantes : Paris, Saint Denis, Montfermeil, Rueil, Bobigny, Vignieux, Trappes, Le Plessis-Bouchard, Le Blanc-Mesnil, Le Raincy, Caen, Rouen, Pont-Audemer, Tours, Romorantin, Château-Chinon, Marseille et Strasbourg.
Il ne s’agit pas d’une panne du réseau, mais d’une perturbation dans l’écoulement du trafic à l’arrivée autour d’un petit nombre de commutateurs (26 sur un total de plus de six cents) : la très grande majorité des appels a pu être acheminée normalement dès le premier appel. On estime à quelques milliers le nombre d’appels non correctement acheminés du premier coup sur un total de 61,9 millions d’appels passés samedi et dimanche. Dans la plupart des cas, le renouvellement d’un appel non correctement acheminé permettait d’obtenir l’aboutissement de la communication.
L’origine du ralentissement réside dans une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP situé à Reims. Cette anomalie logicielle a provoqué une anormalité dans le formatage de la numérotation de certains appels. Ces anormalités ont déclenché les protections de sécurité de vingt-six commutateurs pour éviter une panne du réseau.
L’analyse a montré que le problème de numérotation a été généré par un formatage anormal de certains numéros d’appels sur une plateforme située à l’interface des réseaux IP et commutés. Pour les numéros erronés, la plateforme de gestion a associé en préfixe un numéro caractéristique d’un appel provenant d’un opérateur tiers international.
De ce fait, ces communications étaient dirigées vers le centre de transit international puis vers le réseau commuté français. La détection de l’anomalie de numérotation entraînait le déclenchement d’un mécanisme d’auto-protection. Pour certains commutateurs, cette protection qui s’effectuait via le stockage dans une mémoire tampon des numéros mal formatés, a entraîné le ralentissement de l’écoulement du trafic arrivée par mesure de précaution.
Le réseau de France Télécom est en effet très sécurisé et redondant pour pallier un grand nombre de types de perturbations, de pannes et de tentatives d’intrusion. Dans le cas présent, c’est bien la protection des commutateurs concernés qui a entraîné le ralentissement de l’écoulement du trafic à l’arrivée pour éviter une panne du réseau.
France Télécom s’est attaché dans un premier temps à améliorer la situation en réinitialisant l’ensemble des commutateurs potentiellement concernés, puis a conçu, testé et mis en place un logiciel correctif et enfin l’a implanté à des fins préventives sur l’ensemble du parc concerné.
En concertation étroite avec les pouvoirs publics, France Télécom a veillé à ce que les autocommutateurs concernés auxquels sont rattachés des centres d’urgence soient les premiers à recevoir les modifications préventives développées par France Télécom.
Le Président Thierry Breton a supervisé personnellement l’ensemble des opérations concernant cette perturbation directement sur le terrain à Paris, notamment au centre de supervision du boulevard Brune. Tous les moyens techniques et humains nécessaires pour remédier à ces inconvénients ont été mobilisés. Plusieurs centaines de techniciens sont intervenus.
Source : http://francetelecom.com/fr/espaces/journalistes/commun...
Ralentissement dans l'acheminement d'une partie du trafic téléphonique pendant le week-end des 30/31 octobre
Paris, le 2 novembre 2004
Conclusions de l’enquête diligentée par le Président de France Télécom
Les conclusions de l’enquête commanditée par le Président de France Télécom lui ont été présentées aujourd’hui à 15 heures.
Le ralentissement de l’acheminement du trafic téléphonique au cours de l’après-midi du samedi 30 octobre et du dimanche 31 octobre a perturbé quelques milliers d’appels sur un total de près de 62 millions de communications écoulées pendant ces deux jours.
La cause du ralentissement de l’écoulement du trafic est désormais clairement identifiée.
Elle réside dans une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP situé à Reims. Cette anomalie logicielle a provoqué une anormalité dans le formatage de la numérotation de certains appels. Ces anormalités ont déclenché les protections de sécurité de vingt-six commutateurs (sur un total de plus de 600) pour éviter une panne du réseau.
Le déclenchement de ces protections a eu pour effet de ralentir momentanément l’écoulement du trafic de ces commutateurs réduisant de moins de 1% l’efficacité des appels émis.
La mobilisation des équipes techniques de France Télécom durant tout le week-end a permis de limiter l’ampleur et la durée de ce dysfonctionnement et d’éviter une contamination du réseau.
France Télécom rappelle que l’ensemble du réseau et de ses commutateurs fonctionne normalement depuis dimanche soir.
France Télécom présente toutes ses excuses à chacun de ceux qui ont subi les effets de cette perturbation.
France Télécom a décidé de ne pas facturer à ses clients les communications nationales locales et longue distance passés sur son réseau fixe entre samedi 30 octobre 2004 à 16 heures et dimanche 31 octobre 2004 à 21 heures.
ANNEXE
Dès les premières heures de l’incident, le Président Thierry Breton, qui a coordonné l’ensemble des opérations de retour à la normale a ordonné une enquête précise pour établir la chronologie des faits, déterminer les causes de la perturbation des 30 et 31 octobre 2004 sur certains commutateurs de France Télécom et mettre en œuvre les remèdes appropriés.
Chronologie des faits
Samedi 18h. France Télécom constate un dysfonctionnement dans l’écoulement d’une partie du trafic téléphonique fixe à l’arrivée, les perturbations empêchant de joindre, ponctuellement (et de façon non répétitive) dans certains secteurs géographiques, leurs correspondants.
Vingt-six commutateurs sur un total de 600 centraux de France Télécom sont affectés mais jamais plus de dix d’entre eux ne le sont simultanément.
Une cellule nationale de France Télécom est mobilisée sous l’autorité directe de son Président. Sur le terrain, les techniciens de France Télécom engagent les travaux permettant le retour à la normale par la mise en œuvre d’une procédure de réinitialisation des commutateurs concernés.
Dimanche midi. France Télécom développe une solution logicielle et lance dans une logique de précaution, une procédure préventive sur l’ensemble des commutateurs en service sur le territoire national.
Dimanche après midi. France Télécom annonce que huit commutateurs restent défaillants. En étroite concertation avec les pouvoirs publics, France Télécom communique sur la procédure à suivre en cas de non acheminement d’un appel vers un service d’urgence au cas où la perturbation se reproduirait.
Dimanche 21h. Retour à la normale. Selon la procédure de précaution définie, un patch logiciel a été appliqué sur l’ensemble des commutateurs.
Points saillants.
La perturbation a concerné un ou plusieurs commutateurs situés dans les villes suivantes : Paris, Saint Denis, Montfermeil, Rueil, Bobigny, Vignieux, Trappes, Le Plessis-Bouchard, Le Blanc-Mesnil, Le Raincy, Caen, Rouen, Pont-Audemer, Tours, Romorantin, Château-Chinon, Marseille et Strasbourg.
Il ne s’agit pas d’une panne du réseau, mais d’une perturbation dans l’écoulement du trafic à l’arrivée autour d’un petit nombre de commutateurs (26 sur un total de plus de six cents) : la très grande majorité des appels a pu être acheminée normalement dès le premier appel. On estime à quelques milliers le nombre d’appels non correctement acheminés du premier coup sur un total de 61,9 millions d’appels passés samedi et dimanche. Dans la plupart des cas, le renouvellement d’un appel non correctement acheminé permettait d’obtenir l’aboutissement de la communication.
L’origine du ralentissement réside dans une anomalie logicielle localisée dans un équipement de traitement de la voix sur IP situé à Reims. Cette anomalie logicielle a provoqué une anormalité dans le formatage de la numérotation de certains appels. Ces anormalités ont déclenché les protections de sécurité de vingt-six commutateurs pour éviter une panne du réseau.
L’analyse a montré que le problème de numérotation a été généré par un formatage anormal de certains numéros d’appels sur une plateforme située à l’interface des réseaux IP et commutés. Pour les numéros erronés, la plateforme de gestion a associé en préfixe un numéro caractéristique d’un appel provenant d’un opérateur tiers international.
De ce fait, ces communications étaient dirigées vers le centre de transit international puis vers le réseau commuté français. La détection de l’anomalie de numérotation entraînait le déclenchement d’un mécanisme d’auto-protection. Pour certains commutateurs, cette protection qui s’effectuait via le stockage dans une mémoire tampon des numéros mal formatés, a entraîné le ralentissement de l’écoulement du trafic arrivée par mesure de précaution.
Le réseau de France Télécom est en effet très sécurisé et redondant pour pallier un grand nombre de types de perturbations, de pannes et de tentatives d’intrusion. Dans le cas présent, c’est bien la protection des commutateurs concernés qui a entraîné le ralentissement de l’écoulement du trafic à l’arrivée pour éviter une panne du réseau.
France Télécom s’est attaché dans un premier temps à améliorer la situation en réinitialisant l’ensemble des commutateurs potentiellement concernés, puis a conçu, testé et mis en place un logiciel correctif et enfin l’a implanté à des fins préventives sur l’ensemble du parc concerné.
En concertation étroite avec les pouvoirs publics, France Télécom a veillé à ce que les autocommutateurs concernés auxquels sont rattachés des centres d’urgence soient les premiers à recevoir les modifications préventives développées par France Télécom.
Le Président Thierry Breton a supervisé personnellement l’ensemble des opérations concernant cette perturbation directement sur le terrain à Paris, notamment au centre de supervision du boulevard Brune. Tous les moyens techniques et humains nécessaires pour remédier à ces inconvénients ont été mobilisés. Plusieurs centaines de techniciens sont intervenus.
Source : http://francetelecom.com/fr/espaces/journalistes/commun...
Neoryuki a écrit
La perturbation a concerné un ou plusieurs commutateurs situés dans les villes suivantes : Paris, Saint Denis, Montfermeil, Rueil, Bobigny, Vignieux, Trappes, Le Plessis-Bouchard, Le Blanc-Mesnil, Le Raincy, Caen, Rouen, Pont-Audemer, Tours, Romorantin, Château-Chinon, Marseille et Strasbourg.
La perturbation a concerné un ou plusieurs commutateurs situés dans les villes suivantes : Paris, Saint Denis, Montfermeil, Rueil, Bobigny, Vignieux, Trappes, Le Plessis-Bouchard, Le Blanc-Mesnil, Le Raincy, Caen, Rouen, Pont-Audemer, Tours, Romorantin, Château-Chinon, Marseille et Strasbourg.
Pas eu de probs a Tours
![[:ddr555] [:ddr555]](http://m.bestofmedia.com/sfp/design/usr/fr/smilies/bf/cb/ddr555.gif)