OVHcloud Network Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
Routage interne Roubaix
Scheduled Maintenance Report for Network & Infrastructure
Completed
Afin de mieux gérer le trafic entre nos routeurs de backbone sur Roubaix (rbx-1-6k<>rbx-2-6k<>vss-1-6k<>vss-2-6k<>rbx-99-6k), nous mettons en place une nouvelle architecture de routage. Le basculement vers cette nouvelle archi aura lieu cette nuit à partir de minuit.
Cette maintenance concerne également les liens Roubaix <> Bruxelles (bru-1-6k).

Nous basculerons les liens un par un ce qui ne devrait pas occasionner d'impact sur le trafic.

Update(s):

Date: 2010-07-30 16:34:33 UTC
probleme de MTU resolu avec le passage de nexus 5000 à nexus 7000:

http://travaux.ovh.com/?do=details&id=4426

Date: 2010-03-26 02:26:17 UTC
Le basculement est terminé. Reste un lien à problème (rbx-1<>sw.int-1) passé cette nuit en provisoire. Sera fixé demain matin.

Date: 2010-03-25 23:58:25 UTC
Nous basculons le trafic sur les nouveaux liens sw.int-1 <> vss-1/2 et rbx-99

Date: 2010-02-23 23:00:20 UTC
Nous démarrons les travaux.

Date: 2010-02-23 15:36:26 UTC
Nous poursuivons les travaux cette nuit en espérant que jouer sur la mtu permettra de fixer définitivement le problème et de basculer entièrement sur la nouvelle infra.

Date: 2010-02-21 10:22:41 UTC
C'est bien un probleme de MTU et bien un bug.

Il n'y a pas de problemes entre Nexus 5000 et un 6509 standard ou/et en SXF.
Nous configurons le MTU 9216 et ça passe sans probleme.

Nexus 5000:
policy-map type network-qos jumbo
class type network-qos class-default
mtu 9216
system qos
service-policy type network-qos jumbo


BOOTLDR: s72033_rp Software (s72033_rp-IPSERVICESK9-M), Version 12.2(18)SXF16, RELEASE SOFTWARE (fc2)
interface Port-channelXXX
mtu 9216

Le bug existe entre Nexus 5000 et un VSS en SXI.
Cisco IOS Software, s72033_rp Software (s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SXI3, RELEASE SOFTWARE (fc2)
Il manque 2 bits.
avec

interface Port-channelXXX
mtu 9216

il y a des CRC sur les interfaces
avec

interface Port-channelXXX
mtu 9214

plus aucun probleme.

Nous l'avons remarqué sur la longeur de trame dans les sessions BGP.
Datagrams (max data segment is 9214 bytes):

# ping ip XXXX size 9216 df-bit

Type escape sequence to abort.
Sending 5, 9216-byte ICMP Echos to XXXX, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

-> ca passe à partir de 9214:

#ping ip XXXX size 9214 df-bit

Type escape sequence to abort.
Sending 5, 9214-byte ICMP Echos to XXXX, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/52/204 ms

Nous allons donc finaliser l'infrastructure de routage interne
avec ce \"workaround\" puis reporter le bug à Cisco ...



Date: 2010-02-17 23:50:19 UTC
Le trafic est basculé.

Date: 2010-02-17 22:58:48 UTC
Nous commencons l'opération de basculement.

Date: 2010-02-17 18:27:50 UTC
Cette nuit, travaux sur le réseau au niveau de Roubaix2. Nous basculons le traffic vss-1 <> vss-2 sur une nouvelle infra nexus. En cas de problème, nous reviendrons immédiatement en arrière.

Date: 2010-02-09 02:05:12 UTC
Nous avons retenté les basculements des liens 10G sur la nouvelle infra mais nous rencontrons toujours des difficultés. Nous rebasculons sur l'ancienne config sauf rbx-1 <> rbx-2 qui est le seul lien fonctionnant correctement à travers cette nouvelle infra.

Date: 2010-02-08 23:35:25 UTC
Les liens défectueux sont maintenant réparés. Nous en profitons pour réparer également d'autres liens sur lesquels nous avons relevés des défauts.

Date: 2010-02-08 22:49:59 UTC
Nous commencons la maintenance.

Date: 2010-02-08 18:11:22 UTC
La réparation des liens défectueux aura lieu ce soir à partir de 23:00. En fonction de la façon dont nous aurons avancé sur cette partie, nous embrayerons sur les basculements des liens de routage sur les nouveaux switchs de routage internes.

Date: 2010-02-08 14:38:09 UTC
Nous avons reperé des problèmes sur le lien rbx-1<>vss-2 avant même le début du basculement. Nous avons mis en place une fibre temporaire et prévoyons une intervention de maintenance pour réparer définitivement.
Nous mesurons également une atténuation anormalement élevée sur le liens vss-2 <> rbx-99 que nous allons fixer également.

Date: 2010-02-08 13:41:23 UTC
Nous basculons les liens rbx-1<>vss-2 et rbx-2 <> vss-1

Date: 2010-02-08 10:25:37 UTC
Nous avons modifié la config MTU au niveau des switchs N5 et basculé le lien rbx-1<>rbx-2 dessus. La session BGP est maintenant stable. Nous allons basculer progressivement les autres liens.

Date: 2010-02-05 05:59:53 UTC
Le probleme vient probablement de MTU qui est XXXXX geré sur N5
le XXXX à remplacer par \"mal\", \"differement\", etc

Date: 2010-02-05 05:48:36 UTC
perdu.

on remet les liens comme avant et on remonte les bugs à Cisco ...

Date: 2010-02-05 05:27:54 UTC
On pense que les problemes CRC pourraient venir des optiques
non compatibles (!?) entre les Cisco N5 et les Cisco 6509 ...

on refait un test.

Date: 2010-02-05 05:26:54 UTC
Les maintenances ne se passent pas bien. Nous avons les CRC
entre les routeurs. Nous sommes revenus à la configuration
initiale. Avec beaucoup de peine à cause de bugs :

rbx-99-6k#sh inter ten 9/1
[...]
30 second output rate 90000 bits/sec, 98 packets/sec
[...]

pas moyen de faire passer du trafic.

rbx-99-6k#conf t
Enter configuration commands, one per line. End with CNTL/Z.
rbx-99-6k(config)#inter ten 9/1
rbx-99-6k(config-if)#shutdown
rbx-99-6k(config-if)#no shutdown
rbx-99-6k#sh inter ten 9/1
[...]
30 second output rate 2345596000 bits/sec, 384765 packets/sec
[...]

ce qu'on appele un jolie bug qui fait perdre 2h dans la nuit.
Posted Feb 04, 2010 - 16:35 UTC