Get webhook notifications whenever Network & Infrastructure creates an incident, updates an incident, resolves an incident or changes a component status.
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:
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.