OVHcloud Network Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
VAC1
Incident Report for Network & Infrastructure
Resolved
Nous constatons des instabilités sur l'infrastructure VAC.
Nous investiguons.

Nous avons eu une coupure le 20 dec, 2 fois et le 21 dec
1 fois.

Update(s):

Date: 2015-01-04 20:14:25 UTC
le probleme est fixé.

nous sommes désolés pour la durée de la resolution du task.

Date: 2015-01-04 17:20:53 UTC
Nous avons reconfiguré la mitigation permanante.
# ls mitigationperm-ipv4 | wc -l
17049
IPv4 profitent à nouveau de protection par défaut.

Date: 2015-01-04 17:19:49 UTC
L'oublie de l'ACL:
Le 30-31 octobre 2013, on avait eu un soucis
sur le routeur à Varsovie var-1-6k et nous
avons passé 2 jours pour le stabiliser.
http://travaux.ovh.net/?do=details&id=9596

L'oublie de la reconfiguration du LAG a été
fait à ce moment là .. et 14 mois après ça a
été exploité: depuis le 20 decembre l'infra
VAC1 et VAC2, elle-même, a été la cible des
DDoS et a connu l'instabilité de 10 à 20
secondes environ 25-30 fois sur 3 semaines.
En temps normal, les ACLs bloquent ces DDoS.



Date: 2015-01-04 09:35:19 UTC
Désactivé. On demande au TAC de nous livrer les spares
de M2 et des FAB sur le Cisco Nexus 7009 afin de tout
remplacer.

Date: 2015-01-04 08:32:58 UTC
Le VAC1 a été remis en route. w8

Date: 2015-01-04 08:25:52 UTC
Jan 4 09:23:30 %PLATFORM-2-MOD_REMOVE: Module 6 removed
Jan 4 09:25:23 %PLATFORM-2-MOD_REMOVE: Module 8 removed

Date: 2015-01-04 07:27:02 UTC
le probleme toujours present.

on coupe le VAC1.

on insert les cartes de spare et on va reconfigurer les 2 cartes F2.

Date: 2015-01-04 00:04:03 UTC
On a deconfiguré l'IPv6 qui peut aussi provoquer des problemes
via l'OSPFv3.

Date: 2015-01-03 23:53:21 UTC
Le VAC1 est rebooté. On le laisse se stabiliser.

le VAC1 est remis en route.

Date: 2015-01-03 23:25:09 UTC
On pense, non, on sent (du feeling) que le probleme est un bug
de programmation de TCAM dans le cas où on utilise un VDC avec
un mixte des cartes M2 et F2. Le VDC en question ne dit rien.
Juste l'OSPF se coupe puis se remet.

On a viré toutes les routes progreammées sur le vac1-2-n7, on
a enlevé le \"soft\" de BGP pour eviter de prendre de la RAM et
on a coupé les sessions BGP sur les VDC mixtes. \"sh resources\"
est pourtant correct.

On reboote tout le VAC1 en entier.

Date: 2015-01-02 13:09:26 UTC
Date de livraison prévue: 02-JAN-2015 15:36 (GMT +1)
Ligne: 1.1 Produit: N7K-F248XP-25E= Quantité: 1
Ligne: 2.1 Produit: N7K-F248XP-25E= Quantité: 1

Date: 2015-01-02 12:30:44 UTC
le VAC1 a été redemarré. Donc tous les VDC ont été
rebooté, il n'y a plus aucun code ancien sur le VAC1
qui aurait pu rester à cause de mises à jour à chaud
avec l'ISSU. Tout a été reprogrammé depuis le debut.
Donc tout est vierge.

Le VAC1 a été remis en fonctionnement.

En parallele, on doit recevoir les cartes dans peu de
temps.

Date: 2015-01-02 12:10:13 UTC
On reload le chassis VAC1

admin# reload |
!!!WARNING! there is unsaved configuration in VDC!!!
This command will reboot the system. (y/n)? [n] y




Date: 2015-01-02 11:55:01 UTC
vac1 desactivé. le forwarding des packets s'arrete parfois
et donc l'OSPF tombe, pas l'inverse. on attend les cartes
de spare de Cisco.

Date: 2015-01-02 10:02:14 UTC
Nous avons ouvert le TAC chez Cisco pour recevoir les spares
de cartes.

En attendant et pour mieux debbuger, on a ajouté les routes
statiques sur le VAC1. Ainsi si l'OSPF coupe encore, le
trafic ne coupera pas pour les clients. On pourra alors
debugger à volonté et trouver l'origine du probleme sans
impacter les clients.

Date: 2015-01-02 08:36:09 UTC
le vac1 est desactivé

Date: 2014-12-28 21:50:25 UTC
plus d'alerte. donc tout va bien.

on ferme le thread. on va aussi mettre à jour le VAC2 et VAC3
avec les mêmes parametrages (le VAC3 est déjà en partie sur
la configuraiton de VAC1), mais il reste la RAM prise par le
vacX-2-n7 et la version du NX-OS. on va le faire debut janvier.

Date: 2014-12-25 12:29:46 UTC
le VAC1 est UP à nouveau. on le surveille durant 48H avant
de le declarer \"fixé\"

Date: 2014-12-24 11:38:26 UTC
Le VAC1 est okey. On verifie que sa configuration est
complete. Elle est complete.

On le remet en production durant 1 minute pour valider
que sa configuration est bien complete. Il tourne bien.

On le desactive.

On va le reactiver demain le 25 decembre, et eviter que
si le VAC1 pose encore le probleme, ça arrive le 24 dec.



Date: 2014-12-23 23:34:44 UTC
done:
admin# sh redundancy status
Redundancy mode
---------------
administrative: HA
operational: HA

This supervisor (sup-2)
-----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby

Other supervisor (sup-1)
------------------------
Redundancy state: Standby

Supervisor state: HA standby
Internal state: HA standby


On monitore cette nuit avant de remettre le VAC1 en production.

Date: 2014-12-23 23:30:16 UTC
Tous les EPLDs sont maintenant à jour!

On fait un dernier switchover pour la route.

Date: 2014-12-23 23:08:36 UTC
Good :

Module 1 EPLD upgrade is successful.

On lance le switchover :

admin# system switchover
admin#



Date: 2014-12-23 21:49:28 UTC
le vac1-1-n7 est UP à nouveau. on a dû changer un bon bout de la configuration
puis reload l'ensemble .. fun en barre de chocolat ..

c'est reparti pour 8.2.10 et on acheve le task ..

Date: 2014-12-23 20:08:58 UTC
La carte 8 semble poser des problèmes suite au crash. le pb de LACP peut venir de la.
Nous faisons un unplug/plug de la carte dans le châssis.

Date: 2014-12-23 19:17:17 UTC
L'ensemble des modules sont dans la version 6.2.8a par contre nous constatons toujours des problèmes LACP.

Date: 2014-12-23 18:32:48 UTC
Une des vdc n'envoi plus ses paquets lacp suite au fail lors de l'issu.

Nous relançons un deuxième issu afin de mettre à jour le module 8 correctement.

Date: 2014-12-23 17:17:13 UTC
C'est parti !

Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes non-disruptive reset
2 yes non-disruptive reset
3 yes non-disruptive rolling
4 yes non-disruptive rolling
6 yes non-disruptive rolling
8 yes non-disruptive rolling



Images will be upgraded according to following table:
Module Image Running-Version(pri:alt) New-Version Upg-Required
------ ---------- ---------------------------------------- -------------------- ------------
1 system 6.2(2) 6.2(8a) yes
1 kickstart 6.2(2) 6.2(8a) yes
1 bios v2.12.0(05/29/2013):v2.12.0(05/29/2013) v2.12.0(05/29/2013) no
2 system 6.2(2) 6.2(8a) yes
2 kickstart 6.2(2) 6.2(8a) yes
2 bios v2.12.0(05/29/2013):v2.12.0(05/29/2013) v2.12.0(05/29/2013) no
3 lc1n7k 6.2(2) 6.2(8a) yes
3 bios v2.0.22(06/03/13):v2.0.22(06/03/13) v2.0.32(12/16/13) yes
4 lc1n7k 6.2(2) 6.2(8a) yes
4 bios v2.0.22(06/03/13):v2.0.22(06/03/13) v2.0.32(12/16/13) yes
6 lc1n7k 6.2(2) 6.2(8a) yes
6 bios v2.0.22(06/03/13):v2.0.22(06/03/13) v2.0.32(12/16/13) yes
8 lc1n7k 6.2(2) 6.2(8a) yes
8 bios v2.0.22(06/03/13):v2.0.22(06/03/13) v2.0.32(12/16/13) yes


Do you want to continue with the installation (y/n)? [n] y


Date: 2014-12-23 17:01:21 UTC
Le moment de vérité: nous allons maj le VAC1 en ISSU (6.2.2 vers 6.2.8a puis 6.2.10)

Date: 2014-12-23 15:26:18 UTC
Après 3H avec TAC de Cisco, nous avons pu reintroduire
la configuration dans le routeur mais surtout l'avoir
dans \"sh run\" et donc enregistrer la configuration en
memoire sur le bootflash: puis après le reboot du VDC
le routeur a bien booté sur cette configuration et il
n'a rien oublié.

On est donc sur la bonne voie.

On va appliquer la même methode sur les 6 autres VDC
afin de retrouver les configurations dans \"sh run\" et
dans le bootflash:

Puis on passe à la mise à jour de NX-OS du routeur
vers la derniere version. La mise à jour se fera en
2 etapes:
6.2.2 vers 6.2.8a puis 6.2.8a vers 6.2.10.

Les mises à jour se font à chaud en ISSU. Dans tous
les cas le VAC1 est desactivé.

Une fois en version 6.2.10 on va mettre à jour les
EPLD/FPGA aussi.

Ca avance :)

Date: 2014-12-23 07:21:27 UTC
C'est quand même fou:

vac1-3-n7# sh ip bgp sum
BGP table version is 240527, IPv4 Unicast config peers 4, capable peers 4

vac1-3-n7# sh run | i bgp
vac1-3-n7#

C'est la 1ere fois que je voie que les lignes de commandes
se sont perdues alors que tout reste en place. Je pense que
le probleme vient de là: la configuration semble en place
mais probablement elle n'est plus entierement programmée.
Les bouts qui manquent sont probablement à l'origine des
disfonctionements.

On regarde les backups de la configuration et on met à jour
le chassis en même temps.

Date: 2014-12-23 06:59:52 UTC
On a désactivé vac1. sur vac1-3-n7 la configuration BGP
n'est plus dans \"sh run\" mais sh ip bgp sum montre que
toutes les sessions tournent toujours.

On met à jour le chassis avec une nouvelle version de NX-OS
ça sent une serie de bugs.

Date: 2014-12-22 22:35:19 UTC
on a reactivé le VAC1.

si le VAC1 pose encore le moindre probleme, on va
le desactiver pour une maintenance plus profonde.

Date: 2014-12-22 22:29:51 UTC
le vac1-2-n7 a desormais assez de RAM pour prendre toute
la configuration. il est possible que ça soit l'origine
du probleme même si c'est assez bizarre puisque le probleme
se situe sur vac1-3-n7

Date: 2014-12-22 22:10:43 UTC
la configuration de vac1-2-n7 a sauté .. j'adore les surprises.
bon on est en train de la repousser from scratch.

Date: 2014-12-22 21:39:01 UTC
On ajoute un peu plus de resources dans l'un de VDC
et on redemarre.

admin# reload vdc vac1-2-n7
Are you sure you want to reload this vdc (y/n)? [no] yes
2014 Dec 22 22:37:23 admin %$ VDC-1 %$ %VDC_MGR-2-VDC_OFFLINE: vdc 5 is now offline
2014 Dec 22 22:37:23 admin %$ VDC-1 %$ %SYSMGR-STANDBY-2-SHUTDOWN_SYSTEM_LOG: vdc 5 will shut down soon.
admin# 2014 Dec 22 22:38:11 admin %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 5 has come online

Date: 2014-12-22 21:29:35 UTC
une 2eme fois. on desactive le VAC1

Date: 2014-12-22 20:57:12 UTC
L'OSPF a sauté sur vac1-3-n7.

2014 Dec 22 21:42:27 vac1-3-n7 %OSPFV3-5-ADJCHANGE: ospfv3-16276 [18598] on port-channel1 went DOWN
2014 Dec 22 21:42:29 vac1-3-n7 %OSPF-5-ADJCHANGE: ospf-16276 [18599] on port-channel1 went DOWN
2014 Dec 22 21:43:13 vac1-3-n7 %OSPFV3-4-SYSLOG_SL_MSG_WARNING: OSPF-4-NEIGH_ERR: message repeated 84 times in last 14 sec
2014 Dec 22 21:43:19 vac1-3-n7 %OSPF-4-SYSLOG_SL_MSG_WARNING: OSPF-4-NEIGH_ERR: message repeated 16 times in last 11 sec


Date: 2014-12-21 19:10:03 UTC
Bon, tout semble okey maintenant. C'est probablement un bug.
Une mise à jour vers la derniere version de NX-OS s'impose
dans les jours qui viennent.

On vient de reactiver le VAC1. Les DDoS sont désormais nettoyés
sur les 3 VAC: VAC1 (RBX/GRA) VAC2 (SBG) et VAC3 (BHS).

Date: 2014-12-21 18:26:47 UTC
Tous les UP. Là mon feeling me dit que le vac1-3-n7
est good à nouveau. On regade en profondeur.

Date: 2014-12-21 18:26:17 UTC
Tous les VDC ont redemarré leur L3.

Date: 2014-12-21 18:23:12 UTC
On va quand même faire un switchover de SUP

admin# system switchover
admin#

Date: 2014-12-21 18:16:52 UTC
Bon, on a redemarré le vac1-3-n7 qui pose les problemes.

admin# reload vdc vac1-3-n7
Are you sure you want to reload this vdc (y/n)? [no] y
2014 Dec 21 19:11:11 admin %$ VDC-1 %$ %VDC_MGR-2-VDC_OFFLINE: vdc 3 is now offline
2014 Dec 21 19:11:11 admin %$ VDC-1 %$ %SYSMGR-STANDBY-2-SHUTDOWN_SYSTEM_LOG: vdc 3 will shut down soon.
admin# 2014 Dec 21 19:11:53 admin %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 3 has come online

Il est UP et on a les logs à nouveau.

Date: 2014-12-21 18:16:16 UTC
J'adore les imprevues :)

admin# reload module 2 ?

force-dnld Reboot a specific module to force NetBoot and image download

admin# reload module 2
Active sup reload is not supported.


Date: 2014-12-21 18:07:16 UTC
admin# sh system redundancy status
Redundancy mode
---------------
administrative: HA
operational: HA

This supervisor (sup-2)
-----------------------
Redundancy state: Active
Supervisor state: Active
Internal state: Active with HA standby

Other supervisor (sup-1)
------------------------
Redundancy state: Standby
Supervisor state: HA standby
Internal state: HA standby


Date: 2014-12-21 18:02:38 UTC
admin# reload module 1
This command will reboot standby supervisor module. (y/n)? [n] y
about to reset standby sup
This command will reboot standby supervisor module. (y/n)? [n] y
about to reset standby sup
admin# sh module
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor Module-2 powered-up
2 0 Supervisor Module-2 N7K-SUP2E active *


Date: 2014-12-21 18:02:00 UTC
On va redemarrer la SUP1 qui est en stand-by
puis attendre la syncronisation puis redemarrer
la sup active. Ceci nous permettra de basculer
à chaud sur une nouvelle sup et avoir à nouveau
les logs dans toutes les VDC. Peut-etre.

Date: 2014-12-21 16:36:36 UTC
Le VAC1 est instable. L'un des elements ne tient pas
correctement les sessions OSPF et fait des UP/DOWN.
Parfois. Pas tout le temps.

Lorsque ça arrive, le trafic pris par le VAC1 est nettoyé
mais n'est pas rejecté correctement dans le reseau interne.

On vient de couper VAC1 pour trouver l'origine du probleme.
Le trafic est nettoyé par VAC2 et VAC3
Posted Dec 20, 2014 - 19:49 UTC