La Fibre
Fonctionnement du forum => A lire avant de commencer... => 
Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: vivien le 26 août 2011 à 21:54:33
-
Désolé,
Un petit problème technique a coupé les services de notre hébergeur aujourd'hui de 18h00 à 21h30.
Cela redémarre mais il y a des lenteurs réseaux.
Tout devrait rentrer dans l'ordre dans les prochaines minutes.
Vivien.
-
10 23 ms 23 ms 23 ms th2-crs16-1-be1000.intf.routers.proxad.net [212.27.57.202]
11 23 ms 22 ms 25 ms free-pni2.xe3-0-0.th2.par.as8218.eu [212.27.40.82]
12 23 ms 22 ms 21 ms 83.167.55.23
13 33 ms 29 ms 29 ms xe0-0-0.tcr1.sfr.lyn.as8218.eu [83.167.63.149]
14 30 ms 30 ms 29 ms adeli.gw.tcr1.sfr.lyn.neotelecoms.com [83.167.52.94]
15 * * * Délai d'attente de la demande dépassé.
16 * * * Délai d'attente de la demande dépassé.
17 * * * Délai d'attente de la demande dépassé.
18 * * * Délai d'attente de la demande dépassé.
19 * * * Délai d'attente de la demande dépassé.
20 * * * Délai d'attente de la demande dépassé.
21 * 118 ms 113 ms 195.200.217.68
Envoi d'une requête 'ping' sur lafibre.info [195.200.217.68] avec 32 octets de données :
Délai d'attente de la demande dépassé.
Réponse de 195.200.217.68 : octets=32 temps=696 ms TTL=49
Délai d'attente de la demande dépassé.
Réponse de 195.200.217.68 : octets=32 temps=658 ms TTL=49
Statistiques Ping pour 195.200.217.68:
Paquets : envoyés = 4, reçus = 2, perdus = 2 (perte 50%),
Durée approximative des boucles en millisecondes :
Minimum = 658ms, Maximum = 696ms, Moyenne = 677ms
-
Coupure électrique suite aux orages?
(http://s3.noelshack.com/old/up/lyond0wn-ff54ecab33.png)
-
Je confirme une coupure électrique de courte durée à 18h00.
Les problèmes ont ensuite été réseau.
On parle sans doute du même data-center, le MaxNod (http://www.maxnod.com/) situé près de Lyon.
https://www.youtube.com/watch?v=jU4PcgLvNOc#ws (https://www.youtube.com/watch?v=jU4PcgLvNOc#ws)
-
Tout à fait on avait notre site (et Nitroserv leurs serveurs) chez Maxnod aussi. Le tracert étant le même (et comme t'avais parlé de Lyon, Adeli et Azylog) j'en ai déduis que t'étais aussi chez eux.
Je voyais le réseau qui n'arrivait pas à remonter (on arrivait à pinger *.maxnod.com de temps en temps seulement).
-
Voici la charge du serveur. On voit bien que la panne électrique a été de courte durée :
(https://lafibre.info/images/bistro/201108_charge_lafibreinfo.png)
Voici la vue réseau, depuis Paris :
(https://lafibre.info/images/bistro/201108_reseau_lafibreinfo.png)
-
Nico, je te confirme que http://www.somua.com/ (http://www.somua.com/) est bien sur le MaxNod, voici le traceroute depuis lafibre.info :
# traceroute-nanog -A somua.com
traceroute to somua.com (109.239.145.243), 30 hops max, 60 byte packets
1 195.200.217.253 (195.200.217.253) [AS41405] 0.902 ms 0.896 ms 0.956 ms
2 porte.adeli.biz (91.194.96.2) [AS43142] 0.959 ms 0.877 ms 0.950 ms
3 nitroserv.maxnod.com (91.194.96.127) [AS43142] 0.960 ms 0.921 ms 0.954 ms
4 109.239.145.243 (109.239.145.243) [AS43142] 1.960 ms 1.904 ms 1.954 ms
Tu seras intéressé par les résultats du PingTest (https://lafibre.info/tester-son-debit/pingtest-net-tester-ping-et-packet-loss/) mis en place sur mon serveur... SFR, le seul FAI a peerer avec Adeli sur Lyon va gagner je pense.
Le serveur est directement sur [AS43142] alors que mon hébergeur Azylog a sa propre AS (AS41405) ce qui permet de changer d'opérateur en gardant les IP (Avant AZYLOG était sur un datacenter de Dijon relié à Internet uniquement par Cogent (https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/test-des-peering-du-fournisuer-de-cogent/)...). Le déménagement s'est fait en gardant les IP. Appréciable.
-
Alors je vais pouvoir me fendre de ma petite réponse :
C'est un incident 'à la con'. Les onduleurs de datacenter, c'est une machinerie assez complexe et tout en bout de la chaîne électrique. Tellement complexes d'ailleurs qu'ils embarquent tout un soft de gestion (firmware) et c'est la mise à jour de ce firmware qui a foiré.
Pour une raison qu'il va falloir reproduire (pas moi hein, les p'tits gars de Maxnod), les deux premiers onduleurs ont été mis à jour sans soucis et le 3ème à planter en entraînant les deux autres (je n'ai pas de détail exact là dessus, on verra demain).
Ca a créé une micro-coupure (quelques millisecondes) suffisant pour faire rebooter un maximum de monde dans le data.
Jusque là, rien de méchant, c'est juste dommage pour l'uptime, tout reboote et reprend la main. Ca c'est la théorie.
Dans la pratique, il y a toujours des vérifs de disques qui se passent mal, des secteurs de boot plus à jour, etc ...
Mais chez nous, on a eu un bonus : un problème de conf sur un routeur a fait que le trafic a été blacklisté (oui, tout) et le défaut n'a pas été assez franc pour faire jouer la redondance.
Avec le techos de Maxnod, nous n'avons pas pu faire repartir le routage ce qui m'a valu de me déplacer pour reconfigurer cette saleté. Au passage, j'ai mis en place la contre-mesure pour que ça n'arrive plus à la prochaine coupure de courant (hum). Du coup, la remise en route a prit un peu de temps mais c'est réglé définitivement (mais comme dirait Murphy, le problème ne ce serait jamais reproduit de toute façon).
Voilà un peu plus de détail sur l'épisode certes pas très agréable mais faisant partie des aléas de cet agglomération de technologie qu'est le net.
Julien Escario
-
Merci beaucoup pour les précisions/explications !
-
Je vais rajouter en vitesse que dans l'histoire on s'en sort bien puisque sans casse de matériel.
J'y pense en voyant les techniciens dans le datacenter qui sont encore en train de se battre avec des RAID cassés (et ça, ce n'est vraiment pas agréable ...).
Julien
-
Merci Julien pour tout !
Voici le graphe SmokePing depuis Paris pour montrer que la latence est revenu à la normale :
(https://lafibre.info/images/bistro/201108_reseau_lafibreinfo2.png)
-
Je vais rajouter en vitesse que dans l'histoire on s'en sort bien puisque sans casse de matériel.
J'y pense en voyant les techniciens dans le datacenter qui sont encore en train de se battre avec des RAID cassés (et ça, ce n'est vraiment pas agréable ...).
Julien
Les joies d'etre technicien (en astreinte ou non) et devoir bosser apres un incident electrique dans les datacenters.
Par moment, il y a de grands moments de solitude.
Ca m'est d'ailleurs arrive pas plus tard que dimanche dernier.
-
Le serveur est directement sur [AS43142] alors que mon hébergeur Azylog a sa propre AS (AS41405) ce qui permet de changer d'opérateur en gardant les IP (Avant AZYLOG était sur un datacenter de Dijon relié à Internet uniquement par Cogent (https://lafibre.info/ftth-la-fibre-optique-gpon-ou-p2p/test-des-peering-du-fournisuer-de-cogent/)...). Le déménagement s'est fait en gardant les IP. Appréciable.
Tu es sûr qu'il faut nécessairement un AS pour ça?
Je croyais que l'AS c'était pour échanger des routes en BGP.
-
Si tu a ta propre plage d'adresse IP, il me semble qu'il te faut ton AS.
Il y a échange de route en BGP : AS43142 est l'unique transitaire de AS41405
Avant AS174 (Cogent) était l'unique transitaire de AS4140
Le site de HE n'est toujours pas à jour : http://bgp.he.net/AS41405#_asinfo (http://bgp.he.net/AS41405#_asinfo)
-
Si tu a ta propre plage d'adresse IP, il me semble qu'il te faut ton AS.
Il me semble que non: tu peux très bien avoir ta propre plage IP, même "provider independant", et ne pas avoir d'AS. Dans ce cas, c'est ton opérateur qui s'occupe d'annoncer ta plage depuis son réseau.
Il faut noter que les petites plages d'adresse P.I. on un ENORME INCONVENIENT : elles ne sont pas forcèment visibles depuis partout sur Internet! Et c'est sans doute le cas d'AZYLOG avec ses 255 adresses IP seulement.
https://apps.db.ripe.net/dbweb/search/query.html?searchtext=195.200.217.68
En effet, beaucoup de routeurs essayent de simplifier les routes. Imaginez, pour router correctement vers TOUT internet, un routeur au Japon devrait apprendre spécifiquement la petite route vers Azylog! Si le routeur n'est pas assez puissant pour tout mémoriser, il va tout simplement ignorer ce genre de route trop petite et trop lointaine.
A mon avis, cet inconvénient est plus gênant que le petit avantage de ne pas avoir à changer d'IP 1 fois tous les 5 ans quand l'hébergeur change d'opérateur.
Du coup, je ne comprend pas le choix de nombreux hébergeur de vouloir ABSOLUMENT une plage P.I. C'est un choix assez égoïste, et qui complique les choses, rend Internet moins propre.
D'ailleurs, Vivien, tu dois pouvoir tester ça depuis ton serveur: essayer des routes lointaines (à l'autre bout de la terre) qui sont joignables depuis chez toi mais pas depuis ton serveur chez Azylog.
Leon.
-
Normalement les opérateurs ne filtrent pas à partir de /25 donc pas de souci pour des bloc de /24.
Sur mon SmokePing tu as quelques destinations étrangères.
Si tu as des idées de ping vers l'international, met ta liste je vérifierais avec plaisir et ferais un comparatif des temps de latence Azylog / OVH / OVH / Bouygues Telecom
-
Imaginez, pour router correctement vers TOUT internet, un routeur au Japon devrait apprendre spécifiquement la petite route vers Azylog! Si le routeur n'est pas assez puissant pour tout mémoriser, il va tout simplement ignorer ce genre de route trop petite et trop lointaine.
Et alors?
-
En effet, beaucoup de routeurs essayent de simplifier les routes. Imaginez, pour router correctement vers TOUT internet, un routeur au Japon devrait apprendre spécifiquement la petite route vers Azylog! Si le routeur n'est pas assez puissant pour tout mémoriser, il va tout simplement ignorer ce genre de route trop petite et trop lointaine.
Comme l'a dit Vivien en général on ne filtre que tout ce qui est plus long que /25. Et pour ceux que les poussières (très nombreuses) ennuient et qui filtrent donc à partir d'un peu moins que 25, on prendra soin de se faire annoncer une route par défaut par chacun de ses transits. On peut même imaginer ne garder que les routes peerings (si on pratique ce sport pas tout le temps amusant) et se contenter des routes par défaut pour le reste. Vu le nombre de /24 faramineux, il est inconcevable (ou irresponsable, si certains pratiquent) que l'on décide de simplement faire une croix sur ces destinations.
-
Zorro est arrivé
et il a routé
les paquets.
(Et agrégé les préfixes.)
-
Je reviens là dessus.
Normalement les opérateurs ne filtrent pas à partir de /25 donc pas de souci pour des bloc de /24.
Voici ce qu'on peut lire aujourd'hui sur la mailing-liste FRNOG:
http://www.mail-archive.com/frnog@frnog.org/msg16955.html (http://www.mail-archive.com/frnog@frnog.org/msg16955.html)
Depuis la pénurie d'IPv4, la table BGP augmente chaque jours plus vite
qu'avant, aujourd'hui à 380000 routes les routeurs nous rappellent à
l'ordre.
Hormis la solution de filtrer les annoncent /24 et de poser une default gw
vers les transitaires, avez-vous d'autres solutions ?
Bref, êtes vous vraiment certains que tous les routeurs sensés avoir des "full view" BGP ne filtrent pas les /24? Même les routeurs un peu anciens, avec des capacités limitées?
Leon.