La Fibre
Télécom => Peering Transit (appairage) => 
Transit IP => Discussion démarrée par: Boris de Bouygues Telecom le 09 septembre 2014 à 10:30:11
-
Incident hier soir ?
Hier soir, à 22h00, nous avons eu une baisse soudaine du trafic entrant sur deux de nos 2 transitaires (Tata et Cogent) et du trafic sortant sur deux de nos transitaires (Tata et Level3)
Coté peering, l'intégralité des peering privés, qui constitue la grande majorité du trafic de Bouygues Telecom n'ont pas été impactés, sauf le PNI avec Limelight.
Sur les GIX, je n'ai noté aucun impact sur les 6 GIX où nous sommes présents (France-IX, Equinix Paris, LyonIX, AMS-IX, DEC-IX, LINX)
Savez-vous d'où viennent ces incidents ?
Les graphes :
(https://lafibre.info/images/peering/201409_cacti_8_septembre_2014.png)
Certains AS ne sont pas impactés tandis que d'autres subissent une forte chute de trafic (mais il y a toujours du trafic).
Je ne vois pas de transfert de trafic entre les différents liens que nous avons.
-
Salut,
Rien vu d'anormal de notre côté via L3 / NEOTELECOMS ou nos GIX. Rien vu passer non plus sur les ML $NOG habituelles.
Intéressé de connaitre le fin mot de l'histoire.
Y.
-
Vache, je passe ici et en effet j'ai aussi constaté cette dégradation.
J'analyse mes logs et revient ici.
-
Aucun élèment visible à notre niveau que ce soit chez Cogent, Level3 les Gix ni sur le PNI avec Bouygues.
-
A tout hasard le traf qui manque viendrait pas de ports tous sur le même équipement ? Et cet équipement aurait eu un soucis de SNMP ?
-
J'ai vu des perturbations sur mes graphs de latences vers des opérateurs au travers de Tata. Rien pour Orange ou des destinations nationales de ce que je vois, mais par contre vers l'étranger (UK, ES, US, CA) c'est moche, genre 100-150 ms et des volumes échangés bien moindres. Videotron Canada par exemple je vois tout le volume via Level3 ou Tinet normal mais via Tata j'ai une forte baisse de volume sur cette période. Je pense qu'il y a eu un gros souci TATA, je ne sais pas si vous avez des outils de décision de routage en fonction de critères particuliers (genre Border6 ou autre) qui aurait forcé le reroutage vers Level 3 du coup chez vous ?
Pas d'impact très visible chez nous, mais des ralentissements au travers de Tata sur de l'international donc.
Latence :
(http://syn.fr/images/videotron_ca.png)
A tout hasard le traf qui manque viendrait pas de ports tous sur le même équipement ? Et cet équipement aurait eu un soucis de SNMP ?
Ca n'aurait pas augmenté le volume sur les autres transits et ça aurait donné 0 en volume.
-
Ca n'aurait pas augmenté le volume sur les autres transits et ça aurait donné 0 en volume.
Concernant le volume des autres transit, Boris a précisé qu'il n'y avait pas eu de transfert :
Je ne vois pas de transfert de trafic entre les différents liens que nous avons.
Et si c'est un graphe qui agrège les différents ports d'un transitaires, pas forcement sur un même équipement donc, ça ne serait pas forcement tombé à 0.
-
Pour Bouygues les 3 transitaires sont sur 3 sites distincts et pour le reste du trafic nous ne voyons aucune modification.
Les graphes sont des graphes d'un unique lien (agrégation de plusieurs 10G) mais pas une agrégation de liens différents.
Nous avons un autre lien Tata sur un autre site, qui a été lui aussi impacté, mais un peu moins.
Pour Level3 nous avons aussi un second site et il est aussi impacté en up (pas en down comme sur la capture montrée)
Un exemple d'AS fortement impacté en entrant sur Cogent : AS36666 (GloboTech Communications)
Un exemple d'AS fortement impacté en entrant sur Tata : AS3257 (Tinet)
Sur le PNI Limelight, c'est forcèment Limeligh.
Level3 n'est impacté que sur du trafic sortant. Il est possible que cet trafic soit impacté car l'autre sens était dégradé : En TCP dégrader un sens de la comm perturbe le trafic dans les deux sens.
-
Pour Bouygues les 3 transitaires sont sur 3 sites distincts et pour le reste du trafic nous ne voyons aucune modification.
Les graphes sont des graphes d'un unique lien (agrégation de plusieurs 10G) mais pas une agrégation de liens différents.
Nous avons un autre lien Tata sur un autre site, qui a été lui aussi impacté, mais un peu moins.
Pour Level3 nous avons aussi un second site et il est aussi impacté en up (pas en down comme sur la capture montrée)
Un exemple d'AS fortement impacté en entrant sur Cogent : AS36666 (GloboTech Communications)
Un exemple d'AS fortement impacté en entrant sur Tata : AS3257 (Tinet)
Sur le PNI Limelight, c'est forcèment Limeligh.
Level3 n'est impacté que sur du trafic sortant. Il est possible que cet trafic soit impacté car l'autre sens était dégradé : En TCP dégrader un sens de la comm perturbe le trafic dans les deux sens.
OK je viens de relire plus précisèment, tu as pas mal de perturbations et pas que sur du transit, space... Je n'ai pas autant de perturbations, j'en vois principalement sur Tata comme je disais.
Je vais creuser la question, c'est curieux.
-
Limelight est le seul peering à avoir été impacté.
Limelight étant récupéré sur Paris, savez vous si c'est leur réseau qui arrive sur place ou si c'est comme Akamai ou Netflix, un cache qui est connecté au reste du réseau uniquement par des transitaires ?
Dans ce cas là, si le transitaire n'alimente plus correctement le cache, le débit s'écroule sur le cache.
-
Sur Paris ils ont uniquement des pizza box de caching (sur TH2 et InterXion 1 en tout cas au moins, pas de filer), donc la théorie est intéressante effectivement. Je n'ai pas suivi ces 2 dernières années mais avant ils n'avaient vraiment que du pur caching c'est certain.
-
Y a Rentabiliweb qui vient de poster sur FRnOG :
Hello,
Je fais un peu le tour de mes graphs et je vois des perturbations hier
soir à partir de 22h pendant environ 4h, surtout via le transit Tata
(constaté par un autre opérateur également)
C'est principalement du trafic international dans mon cas, sur Level 3
c'est moins visible mais il semble y avoir eu une légère baisse aussi.
Mes latences vers les US et le Canada via Tata ont pas mal augmenté sur
cette période ainsi que vers l'Angleterre et d'autres pays d'Europe.
Est-ce que quelqu'un aurait des infos sur ce sujet ? (par curiosité)
Merci :)
Cordialement,
Frederic
-
Idem chez Online.
https://status.online.net/index.php?do=details&task_id=93&project=0&status=&perpage=50
-
cf FRnOG, apparemment un gros problème sur le backbone européen de Tata.
Ca sent la grosse saturation après la coupure d'un chemin majeur ça non ?
Et le retour de Tata :
Kindly note that in the event of ongoing major outage in our network in Europe, we faced another outage in Paris, due to which our capacity between London-Paris was down from approx 20:00 UTC, 8th Sept'14 to 00:15 UTC, 9th Sept'14.
However, Our team balanced traffic at around 21:16 UTC, 8th sep'14 to alleviate congestion.
This lead to congestion on other available capacity in this region, leading to packet loss. Our teams balanced traffic as much as possible during this outage to minimize the impact.
We see normal traffic on our backbones since this outage was restored and most of our customers have pushed traffic back on their transit links with us.
-
Lundi dernier, il y a eu une grosse panne Numéricable dans l'Est de la France. Ca serait pas lié ?
-
#AlertePelleteuse ?
-
Lundi dernier, il y a eu une grosse panne Numéricable dans l'Est de la France. Ca serait pas lié ?
Je ne pense pas. De plus, si c'était juste un problème de fibre, étant donné que NC propose ses offres dans toute la France, il doit bien y avoir des chemins redondés / plusieurs trajets possibles etc ...
et le transitaire TATA a annoncé un soucis entre Londres et Paris.
-
En fait TATA etait déjà en mode dégradé depuis qqs jours suite à la perte d'un lien sous-marin Londres->Pays-Bas (ca prend tjrs 3 plombes à réparer ...),
ils ont subit un double effet kiss cool sur la perte d'un lien vers Paris le 08/09 et ils ont galéré pour trouver de la place pour faire passer ailleurs ... au final c'est la réparation de ce 2ème lien qui a résolu effectivement le souci
Mik
-
En fait TATA etait déjà en mode dégradé depuis qqs jours suite à la perte d'un lien sous-marin Londres->Pays-Bas (ca prend tjrs 3 plombes à réparer ...),
Comme d'habitude, les bateaux de pêche qui laissent trainer leurs filets en profondeur et qui arrache tout sur leur passage. Mêmes causes, mêmes endroits, mêmes effets :P
Un de mes fournisseurs de wave me disait lors d'une soirée qu'une sorte de fédération des opérateurs Telecoms a l'échelle du parlement EU essayait de mettre en place des accords avec la fédération EU des pêcheurs pour éviter ce genre d'incidents... Est-ce que ça a marché, aucune idée...
@+
-
Merci pour l'info sur la double panne.
-
Il y a un truc que je ne comprends pas dans la gestion de ces incidents.
Je vois régulièrement sur la liste FRNOG que les opérateurs clients se posent des questions : "qu'est-ce qu'il se passe?" "Vous êtes impactés également"? C'est anormal. Comment est-il possible que des opérateurs impactés ne sachent pas ce qu'il se passe?
* Normalement, un opérateur sérieux a une foultitude d'outils de monitorings. En ayant accès à des sondes réparties un peu partout, dans tous les réseaux (pas que le sien). En utilisant (en automatique) les looking glass. Avec tous les "traceroute" possible et imaginables dans tous les sens, on arrive à savoir énormèment de choses, et surtout comprendre là où ça sature. Un packet-Loss doit pouvoir être détecté très rapidement (moins d'une minute) avec des sondes, et ne surtout pas attendre de voir les graphes de trafic s'effondrer. Pareil avec un ping qui augmente anormalement. Rien que nous, amateurs, pouvons avoir accès à de telles sondes, via RIPE-ATLAS (certes, impossible de faire du "temps réel" avec ça).
* De même, ça n'est pas aux forums ou aux Mailing-Lists de communiquer. C'est à l'opérateur qui a subi la panne de le faire (TATA ici). Normalement, les gros transitaires sérieux (TATA en est un) ont un système de gestion d'incident performant, avec des gens compétent derrière, en nombre suffisant, et ils informent de l'évolution de l'incident en temps réel, avec une heure prévisionnelle de réparation temporaire / définitive. Vu le chiffre d'affaire énorme de ces opérateurs-mastodontes, c'est parfaitement normal. Les clients de ces transitaires doivent pouvoir suivre l'incident en temps réel.
Est-ce que je me trompe et que je vis dans un monde de bisounours? Comment peut-il y avoir un écart aussi énorme entre la théorie et la réalité? Personnellement, je prends peur à chaque fois que je lis "qu'est-ce qu'il se passe" sur FRNOG. Ca ne rassure pas sur la gestion d'Internet. Ca fait vraiment amateur!
Pour re-router le trafic d'un réseau, il faut agir vite. Sachant que les règles de routage automatique ne fonctionnent pas toujours bien dans ces conditions. Donc si on attends plusieurs heures/jours pour comprendre ce qu'il se passe, ça ne peut pas marcher.
Leon.
-
Plusieurs choses :
- souvent le but premier des messages est d'identifier si c'est un incident isolé ou pas
- quand ça demande "qu'est-ce qu'il se passe", c'est plus pour une coupure qu'une saturation ou autre, et quand qqn demande ça c'est qu'il a bien détecté qqch mais cherche à trouver d'où ça vient
- tu n'es pas toujours en direct avec l'opérateur qui a le soucis, il peut vite y avoir 1-2 intermédiaires, compliquant la remontée d'info lors d'une panne
Accessoirement dans une grosse boîte celui qui a l'info de son fournisseur concernant une panne n'est pas forcement en contact avec celui qui monitore certaines choses pour autre chose que de la gestion d'incident (NOC).
Pour illustrer mon dernier point, il y a surement eu des clients qui avaient les strates suivantes :
- le mainteneur de l'opérateur d'infra
- l'opérateur d'infra
- les opérateurs qui ont la moitié du câble en IRU (https://fr.wikipedia.org/wiki/Indefeasible_rights_of_use)
- un opérateur qui va allumer du WDM dessus
- un opérateur qui va acheter une wave
Donc chacun est dépendant de celui du dessus pour avoir l'info concernant la coupure, je te laisse imaginer la cata !
-
Autre chose, quand tu as un lien qui coupe, on va prendre le cas d'un opérateur qui prend une location de wave vers ASM-IX : tu ne sais pas :
- si c'est ton routeur
- si c'est le brassage sous ta responsabilité
- si c'est la fibre de ton opérateur
- si c'est à l'autre bout un problème chez AMS-IX
Avant d'ouvrir des incidents partout, se renseigner permet souvent de trouver le fautif.
-
- tu n'es pas toujours en direct avec l'opérateur qui a le soucis, il peut vite y avoir 1-2 intermédiaires, compliquant la remontée d'info lors d'une panne
Ici, on parle de l'incident TATA. Or, Bouygues est un gros client de TATA, en direct, sans aucun intermédiaire.
Accessoirement dans une grosse boîte celui qui a l'info de son fournisseur concernant une panne n'est pas forcement en contact avec celui qui monitore certaines choses pour autre chose que de la gestion d'incident (NOC).
Là, je n'ai pas compris. Le NOC d'un opérateur a forcèment accès EN DIRECT aux informations des fournisseurs, et communique forcèment EN DIRECT (ou via le support) avec les clients (les clients pro de Bouygues par exemple). Et c'est forcèment le NOC qui MONITORE tout ça, que ce soit monitorer le routage, les infrastructures, les équipements, la téléphonie fixe, mobile, etc... Et le NOC, chez les gros opérateurs, comprends des gens qui monitorent le routage, d'autres qui monitorent les infrastructures (Layer 1), et ils communiquent tous ensemble en temps réel. Ils sont normalement rodés pour gérer les situations de crise en temps réel. C'est pour ça qu'on voit de grandes salles de contrôle avec des écrans géants de partout, et avec des ilots organisés par compétence. Bouygues et TATA sont forcèment organisés comme ça (que ça soit dans une salle ou plusieurs salles, peu importe).
C'est comme la gestion du réseau électrique français RTE : dans le centre des opérations, plusieurs corps de métier travaillent main dans la main pour réagir en temps réel, et c'est parfaitement rodé, l'information circule très vite.
Leon.
-
Ici, on parle de l'incident TATA. Or, Bouygues est un gros client de TATA, en direct, sans aucun intermédiaire.
J'ai généralisé ma réponse, pour le cas de ce sujet voir la suite de ma réponse.
Là, je n'ai pas compris.
Ce que je dis justement c'est que si le NOC a bien sur accès à ces informations, ce n'est pas forcement partagé avec toutes les personnes qui sont susceptibles de voir un incident dans le cadre de leur boulot !
Je ne sais pas ce que fait précisèment Boris, mais ce n'est pas évident qu'il ait accès à tous les tickets ouverts par le NOC.
-
Le NOC gère les coupures et des dégradations forte sur notre réseau.
En cas de coupure, il s ont des règles à suivre pour déclencher le niveau 2 qui va ouvrir un ticket, escalader l'incident si nécessaire, voir même rappeler le fournisseur tous les 1/4 d'heure pour avoir l'avancement en cas de problème vraiment critique.
Là, aucune coupure, donc le NOC n'a pas d'alarme. De mon coté, difficile de voir que ce type de problème est lié à Tata vu que Cogent était fortement impacté par l'Incident.
A noter que j'ai ouvert un incident pour voir si il y a un problème sur notre réseau qui explique que le problème de Tata ait eu des répercussion sur Limelight. Plusieurs personnes se sont penché sur le sujet et le trafic dans les deux sens passe bien intégralement sur le PNI et donc le problème est visiblement coté Limelight, qui doit utiliser Tata pour alimenter ses caches.
-
1) Pour le "qu'est-ce qu'il se passe ?" :
Bah comme dit au dessus, on est tous capables de voir les problèmes et d'identifier depuis quel fournisseur ça se produit, reste que tu peux plus difficilement identifier si c'est général à tous ou plutôt isolé, tu ne sais pas toujours bien la cause exacte non plus du comportement et les mailings permettent d'avoir parfois des infos plus précises et intéressantes sur les choses.
Tout monitorer en détail c'est bien, il faut même, mais ça demande du boulot et surtout ça génère facilement des faux positifs. En particulier parce qu'une IP que tu monitores peut ne plus exister chez l'opérateur en face, qu'un looking glass peut être en maintenance, etc.
2) Le côté pro-actif :
Oui tu es dans le monde des bisounours, Level 3 le fait (bien), mais beaucoup d'autres ne communiquent pas leurs propblèmes, parce que tout a un prix et qu'avoir un service de qualité se paye. A l'heure où tout le monde tire le prix vers le bas, c'est un effet de bord, la partie communication lors d'un incident n'est pas gérée correctement.
Le meilleur exemple de ça c'est Completel. Ca coûte bien moins cher pour avoir des liens P2P que tout autre fournisseur, mais le service est absolument indigne de ce que tu attends d'un opérateur et d'un pro.
Tu sais ce que tu payes...
Et là on parlait de ralentissements, mais pas de coupure, le service Tata fonctionnait au final.
-
Là, aucune coupure, donc le NOC n'a pas d'alarme. De mon coté, difficile de voir que ce type de problème est lié à Tata vu que Cogent était fortement impacté par l'Incident.
Tu veux dire qu'un packet loss important sur certaines destinations ne génère pas d'alarme? De même une chute anormal du trafic (au global ou sur certains liens) ne génère pas d'alarme?
Encore une fois, je suis très surpris! Par exemple, Online dit avoir très rapidement coupé la session BGP avec TATA pour re-router le trafic ailleurs. C'est bien qu'ils ont eu une alarme, qu'ils ont repéré le problème, et qu'ils ont géré manuellement les choses. Tu veux dire que Bouygtel (avec pourtant un réseau beaucoup plus gros) n'a appliqué aucune mesure pendant l'incident? Pourtant, TATA communiquait visiblement pendant l'incident. Online aurait-il une équipe réseau (de 2 ou 3 personnes seulement) plus performante que Bouygtel?
Oui tu es dans le monde des bisounours, Level 3 le fait (bien), mais beaucoup d'autres ne communiquent pas leurs propblèmes, parce que tout a un prix et qu'avoir un service de qualité se paye. A l'heure où tout le monde tire le prix vers le bas, c'est un effet de bord, la partie communication lors d'un incident n'est pas gérée correctement.
Mais là on parle d'un client (Bouygtel) qui verse des centaines de milliers d'euro par an à chacun de ses fournisseur de transit! Comment imaginer une seule seconde qu'il n'y ait pas un support de haute qualité pour un tel client? Encore une fois, TATA a communiqué avec Online.
Et là on parlait de ralentissements, mais pas de coupure, le service Tata fonctionnait au final.
Fonctionnait... avec un packet loss important, donc ne fonctionnait pas de manière acceptable. Les gros opérateurs garantissent un ping et un packet loss au moins sur leur réseau. Donc la prestation n'était pas assurée.
Ce que je dis justement c'est que si le NOC a bien sur accès à ces informations, ce n'est pas forcement partagé avec toutes les personnes qui sont susceptibles de voir un incident dans le cadre de leur boulot !
Je ne sais pas ce que fait précisèment Boris, mais ce n'est pas évident qu'il ait accès à tous les tickets ouverts par le NOC.
Je connais un peu le système de gestion d'incidents d'un gros réseau, pour y avoir eu accès (lecture seule, vue N2). Et tous ces cas sont gérés : une liste d'incidents gérés en transversal et susceptibles d'impacter beaucoup de gens, avec des niveaux de priorité (par degré d'impact). Tous les supports N1/N2/N3 y ont accès, avec des vues différentes. Ces incidents transversaux sont gérés entre intervenants N2/N3, et une partie "communicable au client" (interne ou externe) est éditée en temps réel (=ne pas tout dire). Et un incident client peut être rattaché instantanèment à l'incident transversal, pour hériter de la mise à jour du statut, ce qui permet d'informer de très nombreux clients (internes ou externes) en temps réel. Bref, tous ces cas sont gérables, même en cas de très gros réseau.
Leon.
-
Pour Online, je pense que ce sont eux qui ont contacté Tata et pas l'inverse. Je ne pense pas que Tata ait été pro-actif avec Online. Faudra poser la question à Arnaud ou Mickaël.
Faut voir que Tata est un truc énorme, que Bouygues Telecom est un très gros client français pour nous mais une goutte d'eau dans l'univers Tata. Comme on peut constater que beaucoup d'opérateurs US s'occupent moins bien de clients européens qu'américains parfois (NOC non européen qui ne voit pas la même criticité de sa lorgnette)
Après c'est en premier lieu une question de transparence et d'outils. La transparence c'est prendre le risque de montrer à tous ces clients qu'on a un problème et générer beaucoup de travail de communication avec beaucoup de clients alors qu'une majorité ne remarquera pas ce qui se passe et ne remontera aucun incident. Les outils, c'est avoir un moyen simple et efficace de communiquer avec l'ensemble de ses clients sans passer du temps là dessus au lieu d'en passer sur le problème. Pour un gros acteur, normalement ce ne sont cependant pas les mêmes personnes, mais pour un tier-2, ça arrive et dans tous les cas il y a toujours ce sujet de celui qui gère le problème qui doit prendre du temps pour communiquer la situation à quelqu'un régulièrement.
Pour le coup beaucoup d'opérateurs sont mal équipés pour ça, c'est aussi là où des hosteurs me semblent en avance (OVH, Online) car ils ont l'habitude de la communication de masse et ont plus de vraies équipes de dev proches de leur métier.
La communication chez les opérateurs ça a très souvent été un problème de mon expérience, c'est vrai que ça ne fait pas très sérieux mais bon il faut aussi relativiser, on a tous de la redondance entre plusieurs fournisseurs et si ça coupe, c'est pas comme si on coupait l'électricité dans un hôpital, faut relativiser.
-
oui c'est notre équipe qui a un ouvert un incident chez eux (on le fait quasiment systèmatiquement pour un incident important, surtout là on avait tout coupé, il nous fallait une confirmation de leur part que c'était bien "maitrisé" avant de re-up)
n'importe quel client d'un fournisseur est en droit d'exiger un rapport d'incident, il suffit de leur demander hein ;)
Mik
-
oui c'est notre équipe qui a un ouvert un incident chez eux (on le fait quasiment systèmatiquement pour un incident important, surtout là on avait tout coupé, il nous fallait une confirmation de leur part que c'était bien "maitrisé" avant de re-up)
n'importe quel client d'un fournisseur est en droit d'exiger un rapport d'incident, il suffit de leur demander hein ;)
Mik
Yep, le rapport d'incident heureusement, la question se pose surtout sur la pro-activité et la communication pendant l'incident.
Ceci dit pour Completel même les rapports d'incident post événement sont très difficiles à avoir... (sic)
-
faut pas rever, aucun fournisseur de transit ne communique quand ca va mal,
on est jamais venu me dire "hey, ca deconne vers telle destination on est en train de regarder"
ca serait un peu comme venir te voir le chéquier à la main pour les SLAs ;)
Mik
-
faut pas rever, aucun fournisseur de transit ne communique quand ca va mal,
on est jamais venu me dire "hey, ca deconne vers telle destination on est en train de regarder"
ca serait un peu comme venir te voir le chéquier à la main pour les SLAs ;)
Mik
Exactement :D
Level 3 a tendance à mieux communiquer ceci dit que les autres dans ces cas là, mais c'est plutôt une exception effectivement.
-
faut pas rever, aucun fournisseur de transit ne communique quand ca va mal,
on est jamais venu me dire "hey, ca deconne vers telle destination on est en train de regarder"
Je n'ai jamais dit que c'était au fournisseur de transit de communiquer. Ca peut marcher dans les 2 sens : si le fournisseur a envie de communiquer (en public ou en privé à l'ensemble de ses clients), il le fait; sinon, c'est au client d'ouvrir un incident. Tant que les incidents sont bien traités , je n'ai pas de problème avec ce mode de fonctionnement.
Mais je ne comprends pas ici pourquoi Bouygtel n'a pas déclaré un incident auprès de TATA, ni pourquoi des clients de TATA (ou autre fournisseur de transit) posent demandent "qu'est-ce qu'il se passe" sur la liste FRNOG. Pour moi, ça n'a pas de sens!
Pour Bouygtel, il se peut que l'incident ait été déclaré auprès de TATA, mais dans ce cas, c'est le suivi interne qui ne fonctionne pas.
Leon.
-
Je n'ai jamais dit que c'était au fournisseur de transit de communiquer. Ca peut marcher dans les 2 sens : si le fournisseur a envie de communiquer (en public ou en privé à l'ensemble de ses clients), il le fait; sinon, c'est au client d'ouvrir un incident. Tant que les incidents sont bien traités , je n'ai pas de problème avec ce mode de fonctionnement.
Mais je ne comprends pas ici pourquoi Bouygtel n'a pas déclaré un incident auprès de TATA, ni pourquoi des clients de TATA (ou autre fournisseur de transit) posent demandent "qu'est-ce qu'il se passe" sur la liste FRNOG. Pour moi, ça n'a pas de sens!
Pour Bouygtel, il se peut que l'incident ait été déclaré auprès de TATA, mais dans ce cas, c'est le suivi interne qui ne fonctionne pas.
Leon.
Pour moi il y a plusieurs éléments :
- Boris n'a peut-être pas toutes les informations sur le traitement en cours de l'équipe backbone ou l'équipe backbone n'a pas encore l'information, donc par curiosité il multiplie les canaux de communication pour avoir l'information plus rapidement. C'est le cas aussi pour FRnOG, en général l'idée c'est de voir l'ampleur du problème et de checker qu'une personne mieux placée n'a pas l'information plus rapidement ou n'a pas plus de détails sur l'incident qu'un "on a un problème backbone" du fournisseur
- C'est facile après coup et en ayant le recul de se poser la question par rapport à Tata, mais au moment où Boris indique le problème, la cause a plusieurs conséquences et il n'est pas évident que Tata soit la cause du problème de ce qu'il voit. De mon côté j'ai checké différentes choses y compris au niveau routage pour vérifier la cause et c'était intéressant de discuter ici ou sur FRnOG pour avoir plusieurs angles de vue du problème afin de mieux le cerner. Notamment l'impact sur Limelight n'est pas trivial à comprendre comme ça.
C'est toujours intéressant d'échanger sur les forums ou mailing pour mieux comprendre l'environnement dans lequel on évolue, parce que personnellement j'aime pas me contenter de la communication de mon fournisseur quand je peux avoir plus de détails qui m'aideront à mieux gérer ma redondance à l'avenir.
C'est intéressant de comprendre les causes et les conséquences d'un événement pour mieux debuger les futures situations et mieux préparer ton infra pour ces situations.
Bref, partager des informations et avoir des points de vues divers c'est toujours intéressant, parfois bien plus que la communication de ton fournisseur qui est biaisée par le rapport client/fournisseur.
Pour finir, ça permet d'informer les gens qui n'avaient pas remarqué le problème, ça peut leur être utile.
-
Avec un peu de retard sur ce thread.
Ayant été complétement impacté par le problème Tata je peux te dire comment ça a été géré par chez nous.
Notre astreinte nous appelle car dixit "c'est tout rouge, ça a l air réseau". En // je commence à recevoir des sms.
Je regarde vite fait le monitoring, le graphing, et je me connecte rapidement sur mes routers et je constate rapidement que :
1) les destinations US depuis mon réseau sont HS (normal elles étaient pref via Tata)
2) Tata est quasi HS en Europe
Actions : coupure Tata coté Paris, ouverture de ticket chez Tata, et go IRC pour voir ce que constate les autres.
Et oui parce que Tata ne répondait juste pas pendant l'incident, et donc je voulais savoir si le problème était seulement de mon coté ou pas.
Donc ça peut paraitre bizarre, mais oui le monitoring aide a voir ce qui ne va, mais ce qui aide à comprendre, c'est à la fois les sondes, les ingé qui bossent et la communauté.
PS : j'ai du bataillé pendant une semaine pour avoir un rapport d'incident, je suis un petit client, et même mon commercial Tata que j'aime bien avait pas beaucoup d'info le lendemain...
En revanche pour un gros tel bouygues, ca prouve juste que c'est jamais facile de former un NOC, d'avoir les bonnes procédures d'escalades, etc...
Et surtout tu ne peux pas compter sur le support des gros. Dans le meilleurs des cas ils confirment juste ce que tu as détecté 2h avant, dans le pire des cas ils te bullshitent complétement.