OVHCloud Web Hosting Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
authentification ADSL reseau de collecte
Incident Report for Web Cloud
Resolved
Un de nos fournisseurs de collect ADSL connait de probleme
d'authentification sur son reseau. La consequence est que
pour la connexion ADSL en passant par ce reseau est en panne
depuis 19h45 environ.

Nous sommes en contact avec leur équipes pour savoir quand
le probleme sera fixé.

Update(s):

Date: 2011-09-20 15:45:42 UTC
SFR vient d'ajouter 5 nouveaux BAS pour renforcer
les 8 existants. En tout, tout le trafic passe
maintenant sur 13 (c'est un bon chiffre, il n'y
aura pas de probleme) et donc on ne devrait plus
avoir de perte de packet ni de probleme de bande
passante.

Nous allons deblacklister MIT-1 et MIT-2

Date: 2011-09-20 12:57:15 UTC
SFR a identifié le probleme avec Ericsson:

un client opérateur envoyait un packet mal construit sur
l'interconnexion avec SFR et ce packet plantait le BAS.
Cet opérateur (on ne le connait encore) continuait à
transmettre ce packet jusqu'à dimanche midi. En suite
plus de trace du packet et suite au reboot hard la
situation était revenu à la normal.

Ericsson ont patché le software de BAS et est en train
de verifier le bon fonctionnement en envoyant ce packet
à travers le redback du labo.

Il y aura certainement une mise à jour logiciel à faire
dans les prochaines heures/jours/semaines.

Date: 2011-09-20 08:52:52 UTC
SFR nous aurait fait de remarques sur la
maniere d'être transparent avec nos clients.
Ils n'auraient pas apprecié que ce lien est
public. Nous n'avons rien à cacher depuis
12 ans et notre transparence fait parti de
notre valeur ajoutée que nous ne nous
laissons pas nous enlever.

Nous avons cencuré les paragraphes emotionels
qui ont été écrites à chaud par de personnes
qui ont peu dormi durant la probleme. On
a jugé qu'il apportait peu à la comprehension
de ce qu'il s'est passé.


Date: 2011-09-19 15:43:22 UTC
Nous avons appliqué la meme configuration
sur tous nos LNS. On accepte plus de
connexion de BAS qui ne fonctionnent pas
bien chez SFR à savoir MIT-1 et MIT-2.

Quand le probleme est fixé chez SFR on va
remettre ces 2 BAS.

Date: 2011-09-19 15:42:34 UTC
Nous avons fait une fausse configuration de BAS
avec le MIT-1 et MIT-2 puis killer toutes les
sessions de MIT-1 et MIT-2 plusieurs fois pour
prendre en compte cette configuration. Resultat:
les abonnés ne peuvent pas utiliser MIT-1 MIT-2
ils se reconfigurent automatiquement sur les
BAS qu'on juge en etat de fonctionnement.

Date: 2011-09-19 14:23:45 UTC
On repere les clients qui sont sur ces 2 BAS.
Après le clear de la session, le client passe
sur un autre BAS et là il n'y a plus de probleme.

On regarde comment eviter d'utiliser ces 2 BAS.

Date: 2011-09-19 14:14:22 UTC
d'apres nos recherches avec les clients, le probleme
concerne 2 BAS:

SE800-MIT-1 >> perde de packet
SE800-MIT-2 >> perde de packet+haut latence


Date: 2011-09-19 13:32:43 UTC
Le débit semble correctement mais plusiurs clients
ont des temps de latences importants depuis ce matin.
exemple:
http://twitpic.com/6ncjga/full

On cherche comment fixer ce probleme.


Date: 2011-09-19 11:10:51 UTC
L'incident impacterait la perte des sessions L2TP sur les
offres entreprises ADSL avec ou sans garantie de débit.
Les équipements concernés par l'incident sont 8 BAS SE800
Les BAS de concentration à Paris.

La cause du probleme n'est pas identifiée à ce jour.

Les actions qui auraient été effectuées:
- contrôle des niveaux de charge CPU
- relance des process L2TP
- changement carte SUP
- reload routeur
- isolation d'un noeud
- Isolation d'une carte d'interface instable sur 1 routeur
- restart de chaque BAS


Date: 2011-09-19 07:10:26 UTC
Depuis 3h30, tout est stable d'apres SFR.
On va regarder les cas au cas par cas si il y a des problemes.

Date: 2011-09-19 06:37:18 UTC
SFR a procedé au reboot de CBV1-1

Sep 19 02:06:00: %L2TP-6-TUNNEL: SE800-CBV1-1:756 Max retransmits on packet 238. Closing tunnel
Sep 19 02:06:00: %L2TP-6-PEER: Marking peer SE800-CBV1-1 dead for 120 seconds
Sep 19 02:06:00: %L2TP-6-TUNNEL: SE800-CBV1-1:756 remote abort: Reached max retransmits
Sep 19 02:19:04: %L2TP-6-TUNNEL: SE800-CBV1-1:1073 Max retransmits on packet 2. Closing tunnel
Sep 19 02:19:04: %L2TP-6-PEER: Marking peer SE800-CBV1-1 dead for 120 seconds
Sep 19 02:19:04: %L2TP-6-TUNNEL: SE800-CBV1-1:1073 remote abort: Reached max retransmits
Sep 19 02:20:33: %L2TP-6-PEER: SE800-CBV1-1 marked alive


Date: 2011-09-18 22:51:32 UTC
Nous avons fait le reboot d'un SE1200 (donc plus grand
que SE800) en hard et il faut 4 minutes pour l'avoir à
nouveau en vie.

Sep 19 00:46:16 10g.lyo-1-6k.routers.ovh.net 3105: Sep 18 23:45:53 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet3/1, changed state to down
[...]
Sep 19 00:50:05 10g.lyo-1-6k.routers.ovh.net 3129: Sep 18 23:49:42 GMT: %DTP-SP-5-TRUNKPORTON: Port Te3/1 has become dot1q trunk



Date: 2011-09-18 22:30:57 UTC
Un truc interessant. Notre LNS de Lyon est un redback
aussi. Et on voit que 4 heures avant la panne de la
collect chez SFR, il s'est passé quelque chose chez
SFR qui nous a fait planter le LNS de Lyon. Le meme
software, le même bug.

Sep 17 14:12:51: %LOG-6-PRI_STANDBY: Sep 17 14:12:51: %AAA-6-INFO: AAA: session sync completed
Sep 17 14:19:35: %LOG-6-PRI_STANDBY: Sep 17 14:19:35: %AAA-6-INFO: AAA: start session sync
Sep 17 14:33:35: %LOG-6-PRI_STANDBY: Sep 17 14:33:35: %AAA-6-INFO: AAA: session sync completed
Sep 17 15:38:06: %LOG-6-PRI_STANDBY: Sep 17 15:38:06: %AAA-6-INFO: AAA: start session sync
Sep 17 15:38:33: [0003]: %OSPF-6-INFO: OSPF-16276: Full neighbor xx.xx.xx.xx event: 1 Way
Sep 17 15:38:33: [0003]: %OSPF-6-INFO: OSPF-16276: Neighbor xx.xx.xx.xx fell from Full state to Init state
Sep 17 15:38:38: [0001]: %OSPF-6-INFO: OSPF-16276: Full neighbor xx.xx.xx.xx event: 1 Way
Sep 17 15:38:38: [0001]: %OSPF-6-INFO: OSPF-16276: Neighbor xx.xx.xx.xx fell from Full state to Init state
Sep 17 15:38:40: %L2TP-6-TUNNEL: SE800-ABV-1:15467 Max retransmits on packet 8803. Closing tunnel
Sep 17 15:38:40: %L2TP-6-PEER: Marking peer SE800-ABV-1 dead for 120 seconds
Sep 17 15:38:40: %L2TP-6-TUNNEL: SE800-ABV-1:15467 remote abort: Reached max retransmits
Sep 17 15:38:40: %L2TP-6-TUNNEL: SE800-MIT-1:15451 Max retransmits on packet 9846. Closing tunnel
Sep 17 15:38:40: %L2TP-6-PEER: Marking peer SE800-MIT-1 dead for 120 seconds
Sep 17 15:38:40: %L2TP-6-TUNNEL: SE800-MIT-1:15451 remote abort: Reached max retransmits
Sep 17 15:38:44: [0002]: %OSPF-6-INFO: OSPF-16276: Full neighbor xx.xx.xx.xx event: 1 Way
Sep 17 15:38:44: [0002]: %OSPF-6-INFO: OSPF-16276: Neighbor xx.xx.xx.xx fell from Full state to Init state
Sep 17 15:38:55: %L2TP-6-TUNNEL: SE800-CBV1-1:15461 Max retransmits on packet 9630. Closing tunnel
Sep 17 15:38:55: %L2TP-6-PEER: Marking peer SE800-CBV1-1 dead for 120 seconds
Sep 17 15:38:55: %L2TP-6-TUNNEL: SE800-CBV1-1:15461 remote abort: Reached max retransmits
Sep 17 15:39:06: %L2TP-6-TUNNEL: SE800-MIT-2:15463 Max retransmits on packet 9604. Closing tunnel
Sep 17 15:39:06: %L2TP-6-PEER: Marking peer SE800-MIT-2 dead for 120 seconds
Sep 17 15:39:06: %L2TP-6-TUNNEL: SE800-MIT-2:15463 remote abort: Reached max retransmits
Sep 17 15:39:08: %L2TP-6-TUNNEL: SE800-VEL-1:15455 Max retransmits on packet 8060. Closing tunnel
Sep 17 15:39:08: %L2TP-6-PEER: Marking peer SE800-VEL-1 dead for 120 seconds
Sep 17 15:39:08: %L2TP-6-TUNNEL: SE800-VEL-1:15455 remote abort: Reached max retransmits
Sep 17 15:39:45: %L2TP-6-TUNNEL: SE800-ABV-2:15457 Max retransmits on packet 9278. Closing tunnel
Sep 17 15:39:45: %L2TP-6-PEER: Marking peer SE800-ABV-2 dead for 120 seconds
Sep 17 15:39:45: %L2TP-6-TUNNEL: SE800-ABV-2:15457 remote abort: Reached max retransmits
Sep 17 15:40:00: %L2TP-6-TUNNEL: SE800-MAS-1:15453 Max retransmits on packet 8414. Closing tunnel
Sep 17 15:40:00: %L2TP-6-PEER: Marking peer SE800-MAS-1 dead for 120 seconds
Sep 17 15:40:38: [0003]: %BGP-6-INFO: xx.xx.xx.xx DOWN - Notification sent
Sep 17 15:40:38: [0003]: %BGP-6-INFO: xx.xx.xx.xx send NOTIFICATION: 4/0 (hold time expired) with 0 byte data. mxReadMs=60857
Sep 17 15:40:45: [0003]: %BGP-6-INFO: xx.xx.xx.xx DOWN - Notification sent
Sep 17 15:40:45: [0003]: %BGP-6-INFO: xx.xx.xx.xx end NOTIFICATION: 4/0 (hold time expired) with 0 byte data. mxReadMs=61013
Sep 17 15:40:49: [0002]: %BGP-6-INFO: xx.xx.xx.xx DOWN - Notification sent
Sep 17 15:40:49: [0002]: %BGP-6-INFO: xx.xx.xx.xx send NOTIFICATION: 4/0 (hold time expired) with 0 byte data. mxReadMs=61152
Sep 17 15:41:07: [0002]: %BGP-6-INFO: xx.xx.xx.xx DOWN - Notification sent
Sep 17 15:41:07: [0002]: %BGP-6-INFO: xx.xx.xx.xx send NOTIFICATION: 4/0 (hold time expired) with 0 byte data. mxReadMs=60853
Sep 17 15:41:07: [0003]: %BGP-6-INFO: xx.xx.xx.xx DOWN - Notification sent
Sep 17 15:41:07: [0003]: %BGP-6-INFO: xx.xx.xx.xx send NOTIFICATION: 4/0 (hold time expired) with 0 byte data. mxReadMs=60966
Sep 17 15:41:34: [0002]: %BGP-6-INFO: xx.xx.xx.xx DOWN - Notification sent
Sep 17 15:41:34: [0002]: %BGP-6-INFO: xx.xx.xx.xx send NOTIFICATION: 4/0 (hold time expired) with 0 byte data. mxReadMs=61148
Sep 17 15:45:06: %LOG-6-PRI_STANDBY: Sep 17 15:45:06: %AAA-6-INFO: AAA: session sync completed

et à 19h00 c'était la panne générale. Donc le probleme
vient bien de quelque part du reseau chez SFR et concerne
bien un bug software sur la plateforme redback. En tout
cas c'est notre analyse.

Date: 2011-09-18 22:18:01 UTC
Le reboot est terminé, le VEL-1 est up
et se prend les nouveaux abonnés. Comme
on est à 0h10, il n'y a pas beaucoup de
nouveaux abonnés.

SFR se donne 2h30 pour regarder les logs
et faire de trucs sur le VEL-1 puis à
3h00 du matin, ils doivent prendre la
decision s'ils rebootent tout le reste.


Date: 2011-09-18 21:54:56 UTC
ça revient:

SE800-VEL-1 ovh LNS Local 1 1 Unnamed

lns-1-par-se1200#sh l2tp peer SE800-VEL-1
Peer Name: SE800-VEL-1
Admin State: Up
Local Name: ovh
Vendor: RedBack Networks (Firmware: 0x0600)
Hello Timer: 300 Preference: 10
Maximum Tunnels: 32767 Maximum Ses/Tunnel: 65535
Control Timeout: 3 Retry: 10
Tunnel Count: 1 Session Count: 7
Active Sessions: 7



Date: 2011-09-18 21:30:20 UTC
reboot du VEL-1 en cours

#sh l2tp peer
Conf. Tun Ses
Peer Name Local Name Role Source Count Count
-------------------- -------------------- ---- ------ ----- -----
SE800-VEL-1 ovh LNS Local 0 0 Unnamed DOWN

Sep 18 22:29:08: %L2TP-6-TUNNEL: SE800-VEL-1:508 Max retransmits on packet 277. Closing tunnel
Sep 18 22:29:08: %L2TP-6-PEER: Marking peer SE800-VEL-1 dead for 120 seconds
Sep 18 22:29:08: %L2TP-6-TUNNEL: SE800-VEL-1:508 remote abort: Reached max retransmits


Date: 2011-09-18 21:25:08 UTC
Plusieurs clients nous remontent à nouveau
les problemes de bande passante, même après
les kills de sessions.


Date: 2011-09-18 21:19:41 UTC
A 23h30 SFR prevoit de rebooter en hardware l'un des 8
BAS qui VEL-1 qui a été le premier à etre reloadé
en software cette apres midi.

Il faut 25 minutes environ pour rebooter le BAS
de marque redback. Les clients qui sont sur ce
BAS (dans notre cas il y a un peu moins de 500
abonnés) vont avoir une coupure et devraient
passer par un autre BAS.

Une fois rebooté, SFR prevoit un monitoring de
4 heures.

A 4H du matin, un mini-meeting est prevu pour
savoir s'ils redemarrent les autres BAS avec
la même methode ou une methode plus rapide.


Date: 2011-09-18 21:11:38 UTC
En image, le desastre du wk.
Il s'agit de notre courbe de trafic d'un de nos LNS de Paris
http://yfrog.com/z/h6ojpihj

La probabilitée que le probleme continue demain est très forte !

Date: 2011-09-18 20:59:24 UTC
marseille, bordeaux, lille, lyon, fait

les sessions sont remontés. on a retrouvé les sessions
et la bande passante de clients.



Date: 2011-09-18 20:54:20 UTC
paris fait

Date: 2011-09-18 20:41:26 UTC
kill en cours ..

Date: 2011-09-18 20:40:07 UTC
On a des clients qui perdent les packets et qui
ont des problemes de qualité en ce moment.
Apparament après le kill de la session la qualité
est bonne à nouveau.

On va killer l'ensemble des sessions dans les
10 minutes à venir.

Ceci dit le probleme de fond n'est pas fixé.

Date: 2011-09-18 20:31:48 UTC
Depuis aucune session n'est tombé.



Date: 2011-09-18 18:51:44 UTC
Jusqu'au là SFR aurait procedé à plusieurs redemarrages
software de leurs BAS, c'est à dire de cartes 1G
ou 10G ou des cartes de supervision. Aucune reboot
hardware n'aurait été fait.

Ericson ne voudrait rien faire avant qu'un reboot
hardware de l'ensemble de BAS ne soit effectué.

Comme il y a quelques clients qui fonctionneraient
encore sur les BAS, SFR ne voudrait pas faire le
reboot hardware de ses BAS avant 22h00.

Jusqu'au là SFR monitorerait les tunnels
entre les BAS et nos LNS. si le tunnels tombaient
SFR les relancerait manuellement.

Bref, pas de news avant 22h.

22h, les reboots hardware vont commencer. On
ne sait pas encore si ça ira vite ou pas.


Date: 2011-09-18 17:44:53 UTC
VEL-1 vient de recrasher. Juste le tunnel l2tp.


Date: 2011-09-18 17:35:36 UTC
Tous les BAS ont ete reloader.
Mais un des BAS de Mitry a re-crashe.

Il y a une conf entre SFR et Ericsonn qui a debutee a 19h30.

Les reboots qui ont ete fait sont juste soft ... C'etait juste
une synchro de conf avec un reload !

Il est prevu un reboot hard de tous les BAS a 22h.

On espere avoir plus d'info apres la conf.


Date: 2011-09-18 16:17:36 UTC
5 des 8 BAS de SFR ont ete rebootes.
Les reboot du cote de SFR continuent.

C'est assez long car c'est fait sequentiellement et
SFR regarde pendant 30-45 mins que tout soit stable avant
de passer a un autre BAS.



Date: 2011-09-18 14:01:21 UTC
On a demandé à SFR de couper le port d'interco entre notre LNS de Lyon et SFR.

Date: 2011-09-18 13:26:59 UTC
Qui serait en panne ?
50% des clients \"SFR entreprise\", tous les clients entreprise bouygues
les clients de SFR \"opérateurs\" comme Ovh.

Qui n'est pas impacté ?
les clients SFR/Bouygues grand public qui doivent passer par une autre infrastructure.
nos clients qui sont sur nos propres DSLAMs

Date: 2011-09-18 13:24:07 UTC
SFR a rebooté l'un des BAS. D'où le redemarrage du service.
Ericson (constructeur qui fournit les LNS redback) travaille
sur le probleme pour SFR.

Date: 2011-09-18 13:17:42 UTC
Le service semble redemarrer progressivement. Nous n'avons
pas encore des informations officieles.

Date: 2011-09-18 13:13:21 UTC
L'origine du probleme n'est toujours pas trouve.

Les supports des constructeurs travaillent actuellement
sur le probleme avec SFR pour trouver des solutions.


Date: 2011-09-18 12:28:52 UTC
Nous aurons un point de la part de SFR dans 20 minutes
environ. Pour l'instant un niveau +1 d'astreinte est
arrivé dans le datacentre de SFR et essaie de refaire
marcher le service en changeant les cartes.


Date: 2011-09-18 11:53:17 UTC
Certains BAS ont encore le probleme. La session PPP monte et se kill.
SFR pensait que les BAS d'aubervilliers sont à l'origine du probleme.
Ils ont changé les cartes sur ces BAS. Toujours pareil.

Ils continuent à chercher l'origine du probleme. Pour l'instant,
il n'y a pas une vraie piste.

Qui serait impacté ?
Clients entreprise SFR et les clients opérateurs (entreprise) du SFR
comme OVH seraient impactés.
Les DSLAMs d'Ovh ne sont pas impactés.

Date: 2011-09-18 10:19:18 UTC
Il y a 3 BAS qui sont en fonctionnement au lieu de 7.
Il semble que SFR bascule tout sur ces 3. On les
contact pour savoir pourquoi.


Date: 2011-09-18 10:15:59 UTC
Il y a encore des instabilites du cote des BAS SFR.
Une carte sur le site d'Aubervillier va etre changee vers 13H.

Les clients se connectant sur d'autre BAS qu'Aubervillier n'ont
pas ces problemes

Date: 2011-09-18 09:53:09 UTC
Une nouvelle coupure.

Date: 2011-09-18 09:52:34 UTC
La situation n'est pas encore stable. D'apres les logs nous avons
eu 2 coupures très courte, mais coupures quand même vers 9h02 et
11h10. On remonte l'info chez SFR pour voir comment fixer ce
probleme definitivement.

Date: 2011-09-18 08:05:34 UTC
le source de problème a été confirmé: les BAS chez SFR
ont un bug software sur la plateforme

Date: 2011-09-18 07:39:47 UTC
tout maintenant dans l'ordre, toutes les ppp sessions sont up et stable.

Date: 2011-09-18 05:24:31 UTC
au cours de la dernière 3 heures, tout semble être stable, nous sommes encore la surveillance du réseau.

Date: 2011-09-18 04:37:18 UTC
au cours de la dernière 2 heures, tout semble être stable, nous sommes encore la surveillance du réseau.

Date: 2011-09-18 03:21:33 UTC
au cours de la dernière heure, tout semble être stable, nous sommes encore la surveillance du réseau.

Date: 2011-09-18 02:33:38 UTC
l'origine du probleme est identifiée: il s'agit d'un bug sur
les BAS redback. SFR est en train de les rebooter. un ticket
a été créé chez Ericson qui fournit les redback

Date: 2011-09-18 01:08:32 UTC
la plupart des sessions sont up mais toujours pas stable, nous travaillons toujours avec SFR pour le résoudre.

Date: 2011-09-18 00:48:30 UTC
Ok, il est presque fixe, mais nous ne sommes pas encore sûr si c'est vraiment ok, nous sommes toujours vérifier avec SFR pour s'assurer que tout dans l'ordre.

Date: 2011-09-18 00:23:17 UTC
Depuis 2h03 nous voyons le trafic augmenter sur
l'interco LNS SFR

Date: 2011-09-18 00:19:44 UTC
L'origine du probleme semble d'être difficile à identifier.
Nous avons fournit à nouveau tous les renseignements de
notre côté afin d'aider le debug de notre côté.

D'apres le SFR l'impact est sur l'ensemble du réseau. Mais
nous on ne voit pas de diminution de trafic entre SFR/OVH
sur l'hébergement. Bizarre.

C'est la première fois qu'un tel problem touche tous les BAS.
Jusqu'au là ça touchait un BAS au plus. SFR pense que le
problem pourrait venir entre leurs BAS et proxy-radius-sfr


Date: 2011-09-17 23:43:26 UTC
Nous travaillons ainsi avec leur équipe et l'échange des informations entre nous afin de résoudre le problème.
Nous n'avons pas encore de l'heure de retablissement du service.

Date: 2011-09-17 23:28:37 UTC
Nous continuons les investigations au près de SFR.
Nous n'avons pas encore de l'heure de retablissement du service.

Date: 2011-09-17 22:42:23 UTC
A notre niveau 100% de nos clients ADSL qui passent
par le reseau collect de SFR sont impactés par la
panne.

Il n'y a pas d'impact sur nos DSLAMs

A 22h45 et 23h15 nous avons eu une partie de clients
qui sont revenus pendant 15 minutes.


Date: 2011-09-17 22:39:40 UTC
D'apres les graphes de trafic à partir de reseau SFR
les clients directs de SFR ne semblent pas d'être
impactés par cette panne. Le trafic est stable sur le
peering SFR/Ovh.

Bouygues un autre client de SFR pour la collect ADSL
ne semble pas non plus être impacté par cette panne.

Nerim semble d'être impacté par cette panne.

Date: 2011-09-17 22:28:24 UTC
Apparament le probleme est générale sur leur reseau et
plusieurs de leurs clients comme Ovh sont impactés. Le
probleme ne se situe pas sur notre reseau.
Posted Sep 17, 2011 - 20:29 UTC
This incident affected: Internet Access || FTTH.