OVHcloud Network Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
vss-1-6k
Incident Report for Network & Infrastructure
Resolved
Suite à une création d'un port channel, le chassis 1 a rebooté. Le routeur
a basculé sur le chassis 2.

Update(s):

Date: 2009-01-17 11:33:15 UTC
11:09:18 tout est up à nouveau.

Nous avons configuré pendant le redemarrage les ports 10G que nous
voulions mettre en place. On laisse donc tranquil les ports 10G. et
pour les ports 1G nous avons une methode qui marche (pour l'instant).

La vraie solution c'est la nouvelle version d'IOS qui fixe le bug.

Date: 2009-01-17 09:42:39 UTC
On repart pour un tour. Visiblement la configuration des ports 10G
ne peut pas se faire sans une panne :(

Date: 2009-01-15 13:42:11 UTC
Le chassis est syncro.

Les cartes boote. Il faut compter 5 minutes.

Date: 2009-01-15 13:35:22 UTC
Suite à un ajout trop rapide des commandes, le slave a rebooté.
Nous allons couper les cartes pour resyncroniser l'ensemble.

Date: 2009-01-07 14:12:00 UTC
Donc:
le probleme à la base est dû à une configuration \"importante\" en terme
de port channel et des ports. En gros, il y a pas mal des lignes de
commandes. Le Cisco met beaucoup de temps pour syncroniser chaque nouvelle
commande que nous ajoutons au routeur. Par exemple ajouter un nouveau
switch d'une baie. Et donc lors d'un ajout des nouvelles cartes que nous
avons fait hier, tout a été correctement, mais lors que nous avons lancé
le robot pour ajouter la configuration sur le routeur, le routeur a pris
les commandes puis a essayé de syncroniser avec le slave et comme le slave
mettait trop de temps pour repondre, il a pensé qu'il est en panne et l'a
rebooté. Donc, c'est le bug principal.

Une fois que le slave a été rebooté, nous nous sommes en retrouvé avec le
même bug mais dans la phase de demarrage. Le master essayaient de syncroniser
les configurations des cartes actives avec le slave et comme le slave prennait
trop de temps pour repondre, il a ordonné de le rebooté.

Solution:
- il faut taper de nouvelles commandes \"tranquilement\", ligne par ligne avec
quelques 5-10 secondes entre chaque commande dans l'IOS. il faut donner le
temps au master de syncroniser chaque ligne de commande avec le slave
- si le slave a été rebooté et ne veut pas syncroniser la configuration, il
faut retirer tous les cartes actives du master, laisser booter le slave, laisser
syncroniser master avec slave, et une fois que tout est syncro, redemarrer les
cartes. c'est ça qui provoque une coupure de 5-10 minutes.

Maintenant que nous savons l'origine du probleme (un bug dans l'IOS SXI) et nous
savons comment le contourner, il n'y a plus qu'à mettre en oeuvre notre
théorie.

20 minutes plus tard:
- le master + le slave est en fonctionnement avec toutes les cartes actives. YES !
- nous allons essayer d'ajouter maintenant les configurations qu'il faut mettre en
place pour les nouvelles baies qu'on doit mettre en production. on va y aller
tranquilement.

Date: 2009-01-07 13:50:30 UTC
Nous avons resolu le probleme de la syncro entre master et slave.
Par contre le slave a rebooté. Nous allons recommencé la maintenance
avec 5 minutes d'indisponibilitée.

Date: 2009-01-07 05:36:45 UTC
Tout est à nouveau detecté et le routeur est syncro. Par contre la
configuration des cartes du slave a disparu. Et suite à une remise
en place de la configuration, elle ne marche pas. Nous allons
chercher l'origine de ce probleme.

Date: 2009-01-07 05:15:11 UTC
Toutes les cartes du master sont up. Tous les serveurs sont à nouveau
joinables.

On insert maintenant les cartes du slave.

Date: 2009-01-07 05:06:24 UTC
Le master et le slave sont syncronisé.

Jan 7 06:03:59 GMT: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync succeeded
Jan 7 06:03:57 GMT: %PFREDUN-SW1_SPSTBY-6-STANDBY: Ready for SSO mode
Jan 7 06:04:00 GMT: %RF-SW2_SP-5-RF_TERMINAL_STATE: Terminal state reached for (SSO)

Nous redemarrons les cartes dans le master. Les serveurs vont revenir progressivement.


Date: 2009-01-07 04:56:28 UTC
Nous allons tenter de demarrer le systeme master/slave sans les cartes
puis si le systeme prend rajouter les cartes dans le systeme une après
une.

Cette opération va provoquer une coupure d'accès Internet aux serveurs
de Roubaix 2 pendant environ 10 minutes (tous les serveurs 94.23.0.0/16).
Merci de votre comprehension.

Date: 2009-01-06 16:37:45 UTC
Le bug CSCsm76792 empeche le slave de booter. Le timeout est trop faible pour
syncroniser correctement toute la configuration entre le master et le slave
(elle est grande la configuration) et le master n'a pas de reponse de la part
du slave et lui demande de redemarrer. D'où le boot en boucle.

· CSCsm76792
Symptoms: A standby supervisor power cycles over and over on boot up. The following errors are
seen:
May 14 19:21:09.188 EDT: %RF-SP-3-NOTIF_TMO: Notification timer Expired for RF Client:
Cat6k Power(1318)
Conditions: This has been experienced on a Catalyst 6500 with dual supervisors running Cisco IOS
Release 12.2(33)SXH2a and Cisco IOS Release 12.2(33)SXH3.
Workaround: There is no workaround.

La version SXH4 n'a pas ce bug mais elle ne permet pas d'avoir plus de 121 port channels.
la version SXI (que nous avons) a ce bug là mais permet d'avoir plus de 121 port channls.

On cherche une solution.

Date: 2009-01-06 13:44:04 UTC
Le chassis slave ne veut pas finaliser la procedure de boot. Il reboot en boucle.
Nous fonctionnons sur le chassis master. Il n'y a pas de degradation de service.

Un TAC a été ouvert chez Cisco. Nous sommes en contact avec un ingénieur cisco
pour resoudre ce probleme.

Date: 2009-01-06 11:59:09 UTC
Jan 6 12:47:59 GMT: %IDBMAN-4-CONFIG_WRITE_FAIL: Failed to generate configuration for interface Po161
Jan 6 12:48:19 GMT: %PFREDUN-SW2_SP-7-KPA_WARN: RF KPA messages have not been heard for 27 seconds
Jan 6 12:48:29 GMT: %RF-SW2_SP-5-RF_RELOAD: Peer reload. Reason: Proxy request to reload peer
Jan 6 12:48:29 GMT: %SYS-SW1_SPSTBY-5-RELOAD: Reload requested - From Active Switch (Reload peer unit).
Jan 6 12:48:31 GMT: %VSLP-SW2_SP-2-VSL_DOWN: Last VSL interface Te2/5/5 went down

Jan 6 12:48:31 GMT: %VSLP-SW2_SP-2-VSL_DOWN: All VSL links went down while switch is in ACTIVE role
4w0d: SW2_SP: Switch 1 Physical Slot 5 - Module Type LINE_CARD removed
4w0d: SW2_SP: Switch 1 Physical Slot 1 - Module Type LINE_CARD removed
Jan 6 12:48:35 GMT: %XDR-6-XDRIPCNOTIFY: Message not sent to slot 23/0 (23) because of IPC error queue flush. Disabling linecard. (Expected during linecard OIR or system reloads)
4w0d: SW2_SP: Switch 1 Physical Slot 6 - Module Type LINE_CARD removed
Jan 6 12:48:37 GMT: %SATVS_IBC-SW2_SP-5-VSL_DOWN_SCP_DROP: VSL inactive - dropping cached SCP packet: (SA/DA:0x4/0x6, SSAP/DSAP:0x1D/0xAB, OP/SEQ:0x500/0xB34, SIG/INFO:0x1/0x502, eSA:0000.0500.0000)
Jan 6 12:48:41 GMT: %XDR-6-XDRIPCNOTIFY: Message not sent to slot 24/0 (24) because of IPC error queue flush. Disabling linecard. (Expected during linecard OIR or system reloads)
4w0d: SW2_SP: Switch 1 Physical Slot 7 - Module Type LINE_CARD removed
4w0d: SW2_SP: Switch 1 Physical Slot 8 - Module Type LINE_CARD removed
4w0d: SW2_SP: Switch 1 Physical Slot 9 - Module Type LINE_CARD removed
Posted Jan 06, 2009 - 11:53 UTC