rssLink RSS for all categories
 
icon_blue
icon_green
icon_green
icon_orange
icon_red
icon_green
icon_green
icon_orange
icon_red
icon_orange
icon_red
icon_green
icon_green
icon_blue
icon_red
icon_green
icon_green
icon_blue
icon_red
icon_red
icon_green
icon_red
icon_orange
icon_red
icon_orange
icon_green
icon_green
icon_red
icon_green
icon_blue
icon_green
icon_orange
 

FS#4411 — routage le samedi 24 juillet au soir

Attached to Project— Reseau Internet et Baies
Incident
Tout le réseau
CLOSED
100%
Le contexte:
nous avons 2 travaux importants sur le reseau: cette nuit (25 juillet)
et lundi 27 juillet soir.
http://travaux.ovh.com/?do=details&id=4328
http://travaux.ovh.com/?do=details&id=4369

Il s'agit de travaux de maintenance sur la fibre optique Roubaix/London
et Roubaix/Bruxelles.

Du coup on a boosté la fin de travaux sur les securisations du reseau
à travers london/amsterdam et frankfurt/paris. ça a été monté jeudi.
http://travaux.ovh.com/?do=details&id=4400
http://travaux.ovh.com/?do=details&id=4401

Avant ces travaux, à 20h03 le routeur à london a crashé puis en plus
il n'est pas revenu tout seul. probleme de boot, on a dû le reprendre
en cable serie pour le finir de booter.
http://travaux.ovh.com/?do=details&id=4408

Dans la foulé frankfurt a crashé pour cause de la mémoire. puis
amsterdam a aussi crashé. en 1 heure 3 routeurs.

on a mis du temps à restabiliser la backbone et surtout remonter
frankfurt. et qui dit frankfurt dit zurick milano, prague et
vienne. uniquement la france et espagne n'ont pas été impacté:
http://p19.smokeping.ovh.net/ovh-server-statistics/show.cgi?target=PING

après l'analyse on pense qu'avec les securisations qu'on a mis en
place et les données du BGP à syncroniser en plus, le routeur london
amsterdam et frankfurt ont été full en RAM non fragmenté. Ils n'ont pas
été redemarré depuis pas mal de temps et la RAM s'est fragmenté.
Mais c'est aussi lié à MPLS. sans ça marche. avec le routeur n'a plus
de RAM. du coup on a coupé MPLS et remis frankfurt lien par lien.
le routeur est stable avec 200Mo de libre sur 1Go.

l'une des solutions a été commandée il y a 3 semaines et arrive dans
5 semaines. Il s'agit de 2 ASR1000 pour les routes collector. au lieu
de monter 1 session BGP entre chaque routeur, on ne va monter que 2
sessions BGP par routeur et les 2 collectors vont calculer les routes
puis propager les informations aux autres routeurs de maniere simple.
ça va prendre aussi moins de CPU et moins de RAM. surtout quand le
reseau est securisé, à travers les boucles, les mêmes informations
d'un même routeur arrivent par differents chemins à differents moment
vers chaque routeur et chaque routeur est obligé de tout calculé
plusieurs fois. ça fait beaucoup de calcul en permance. en gros,
la configuration actuelle est arrivée à son bout et il faut la faire
évoluer. ça sera fait. une autre solution serait les confederations
en BGP afin que les changements se fassent uniquement dans la
confederation. on prefere les routeurs collector.

2ème solution consiste à changer les cisco 6509 par les nexus 7016.
on a reçu un pour le labo et on le teste. On attend le mois de septembre
pour passer la commande pour 5 nexus 7016 parce que ... les cartes
qu'il nous faut n'existent pas encore. seulement à partir de mois de
septembre ...

Par contre certains clients FR et ES ont été aussi impacté par ces
problemes surtout sur le vss-1 et vss-2: lorsque le routage change et
il faut recalculer les tables BGP, les routeurs vss ont vraiment du mal.
ils prennent 100% du CPU pendant très long temps et le process ARP ne
repond pas aux demandes ARP des serveurs. OSPF se coupe, BGP aussi,
les serveurs de clients expirent la MAC du routeur et ne recoivent pas
la reponse à la requete. et ça ping pas. avec le route collector on va
diminuer le CPU pour le BGP. ça va déjà regler pas mal le probleme.
Une 2ème solution devra être mise en place pour deplacer le proxy-arp
des reseau du routeur vers un serveur spécialement conçu pour ça. Ca
sera à coder et à mettre en place.
Date:  Sunday, 25 July 2010, 00:57AM
Reason for closing:  Done