RSS for all categories
FS#3830 — Routage interne Roubaix
Attached to Project— Reseau Internet et Baies
| Maintenance | |
| Tout le réseau | |
| CLOSED | |
 |
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.
Date: Friday, 30 July 2010, 20:36PMCette 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.
Reason for closing: Done
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.
On pense que les problemes CRC pourraient venir des optiques
non compatibles (!?) entre les Cisco N5 et les Cisco 6509 ...
on refait un test.
perdu.
on remet les liens comme avant et on remonte les bugs à Cisco ...
Le probleme vient probablement de MTU qui est XXXXX geré sur N5
le XXXX à remplacer par "mal", "differement", etc
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.
Nous basculons les liens rbx-1<>vss-2 et rbx-2 <> vss-1
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.
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.
Nous commencons la maintenance.
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.
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.
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.
Nous commencons l'opération de basculement.
Le trafic est basculé.
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 ...
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.
Nous démarrons les travaux.
Nous basculons le trafic sur les nouveaux liens sw.int-1 <> vss-1/2 et rbx-99
Le basculement est terminé. Reste un lien à problème (rbx-1<>sw.int-1) passé cette nuit en provisoire. Sera fixé demain matin.
probleme de MTU resolu avec le passage de nexus 5000 à nexus 7000:
http://travaux.ovh.com/?do=details&id=4426