OVHcloud Network Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
zur-1-6k/sbg-g2-nc5 - Accès Strasbourg depuis la Suisse.
Incident Report for Network & Infrastructure
Resolved
Nous rencontrons des problèmes d'accès au Datacentre de Strasbourg depuis la Suisse.

Nous investiguons.

Update(s):

Date: 2017-03-24 17:16:45 UTC
Nous ne constatons plus de problème depuis et vers zurich. Nous continuons les investigations avec Cisco pour trouver une solution définitive.

Date: 2017-03-24 16:04:55 UTC
Nous avons remis en service tous les PNI sur zur-1-6k et TIX.

Date: 2017-03-24 14:33:01 UTC
La source du problème a été identifié. Depuis la mise à jour des NC5, nos nouveaux cœurs de réseau de datacentres à SBG, ces équipements ont un comportement anormal qui ajoute un bit à 1 dans l'entête 802.1q, le bit CFI (Canonical Format Identifier).

Ce bit est normalement utilisé historiquement pour les rétro compatibilités entre les réseaux Token Ring / FDDI (CFI = 1) et Ethernet (CFI = 0).

Mais avec la disparition des réseaux Token Ring et la norme 802.1ad (S/C-VLANs) et 802.1ah, ce bit a été réutilisé avec un autre usage DEI (Drop Eligible Indicator) et est implémenté en tant que tel dans certaines stacks 802.1q depuis 2011. Ce flag DEI permet de sélectionner les paquets qu'un équipement peut dropper en cas de congestion réseau.

Pour plus de de détails, vous pouvez consulter la doc VLAN sur Wireshark, qui explique très bien le rôle de ce bit CFI.

Cisco doit nous confirmer pourquoi depuis la dernière version qui est sensée stabiliser les nc5, l'équipement set le bit CFI/DEI à 1, ce qui génère un drop sur zur-1-6k pour le forwarding, comme pour les paquets puntés au CPU, car celui ci ne comprend pas pourquoi ce paquet Ethernet contient un flag qui indique un paquet Token Ring.

En conséquence, nous avons trouvé avec Cisco un workaround, le temps qu'ils analysent pourquoi et nous produisent un fixe : nous avons passé le lien en native vlan, ce qui évite d'avoir l'entête 802.1q et donc ce bit CFI = 1 entre sbg-d1-a75 et zur-1-a72. Les paquets traversent donc désormais correctement le sbg-g1-nc5.

Nous allons valider en remettant en service un PNI sur zur-1-6k.

Date: 2017-03-23 22:36:55 UTC
Nous allons devoir mettre en place un serveur de capture du trafic traversant sur sbg-g2-nc5 pour continuer le troubleshoot et valider les hypothèses identifiés ce 12 dernières heures. En effet, lorsque nous pinguons zur-1-6k à travers le nc5, et ce depuis sa mise à jour, le paquet reçu par zur-1-6k semble être un paquet Token Ring alors qu'il s'agit bien d'ICMP dans Ethernet ^^

Nous allons mettre en place ce serveur de capture ASAP afin de comprendre avec Cisco pourquoi le trafic traversant sbg-g1/g2-nc5 fait une mutation Ethernet => Token Ring ... Et surtout pourquoi cela n'affecte que le trafic partant vers zur-1-6k.

Date: 2017-03-23 19:44:48 UTC
Nous continuons d'investiguer avec les ingénieurs de Cisco. Il n'y a aucun impact sur le trafic car tout a été routé ailleurs.

Date: 2017-03-23 16:05:27 UTC
Nous n'arrivons pas à fixer le problème, nous escaladons le case chez Cisco.

Date: 2017-03-23 15:46:20 UTC
Nous sommes en train de déplacer l'uplink de Zurich sur sbg-d1-a75 / sbg-g1-a9 / sbg-g1-nc5.

Si cela ne fixe toujours pas, nous mettons en place une escalade chez Cisco.

Date: 2017-03-23 14:28:34 UTC
Nous avons identifier que le routeur zur-1-6k, sur le chemin zur-1-6k <> sbg-g2-nc5 ignorait tous les paquets puntés au CPU (exemple : icmp), alors que sur le chemin zur-1-6k <> sbg-g2-a9.

Nous avons reloadé zur-1-6k. Mais le problème semble persister.

Nous continuons nos investiguations avec Cisco pour comprendre le problème.



Date: 2017-03-23 12:24:27 UTC
Nous avons isoler nos peering sur zur-1-6k.

Nous continuons les investigations.

Date: 2017-03-23 12:00:04 UTC
Nous avons isolé nos peerings en Suisse, le problème n'étant pas identifié.
Posted Mar 23, 2017 - 11:56 UTC
This incident affected: Infrastructure || SBG (SBG1, SBG3, SBG4).