Date de l’incident : 23 juillet 2026 Durée : 3h19 (16:49 → 20:08 CEST) Impact : Perte de connectivité sur le VLAN 1234 pour les usages concernés Gravité : Moyenne
TL;DR
Un switch de coeur de réseau (QFX) est tombé en panne de manière silencieuse : ses ports restaient actifs physiquement, mais l’équipement ne répondait plus et ne transitait plus le trafic. Les routeurs voisins, n’ayant aucun mécanisme de détection de cette panne, ont continué à envoyer du trafic vers une destination qui n’existait plus. Résultat : du blackholing — le trafic partait vers le néant.
La timeline
16:49 ── Alerte détection incident
│
├── 16:55 ─── 1er ingénieur prend en main
├── 17:10 ─── Diagnostic : switch ne répond plus
│ (ni console RS232, ni SSH/IP)
├── 17:30 ─── 2ème ingénieur mobilisé
├── 18:00 ─── 3ème ingénieur mobilisé
├── 18:15 ─── Ingénieur sur site au datacentre
│ (vérification physique)
├── 18:45 ─── Identification du blackholing
│ sur core02.pa2.par
├── 19:15 ─── Création de routes statiques
│ more-specific sur core02
├── 19:45 ─── Trafic rétabli sur VLAN 1234
└── 20:08 ─── Incident résoluL’architecture (simplifiée)
Avant l’incident
INTERNET
│
│ BGP
│
┌────────────┴────────────┐
│ │
┌─────┴─────┐ ┌──────┴─────┐
│ core01 │ OSPF/ │ core02 │
│ EX │◄──BGP────► │ EX │
│ │ (inactif) │ │
└─────┬─────┘ └──────┬─────┘
│ │
│ │
┌─────┴─────────────────────────┴─────┐
│ qfx32.pa2.par │
│ (QFX) │
│ [ OK ] Actif │
└─────────────────┬───────────────────┘
│
VLAN 1234 / 2345 / 3456
│
┌─────┴─────┐
│ Serveurs │
└───────────┘Pendant l’incident
INTERNET
│
│ BGP
│
┌────────────┴────────────┐
│ │
┌─────┴─────┐ ┌──────┴─────┐
│ core01 │ │ core02 │
│ [+] OK │ │ (!) Reçoit │
│ │ │ du trafic │
└─────┬─────┘ └──────┬─────┘
│ │
│ │
┌─────┴─────────────────────────┴─────┐
│ [!] qfx32.pa2.par │
│ (PANNE SILENCIEUSE) │
│ Ports UP mais ne répond plus │
└─────────────────┬───────────────────┘
│
[XX] BLACKHOLING
(trafic jeté dans le vide)
│
┌─────┴──────┐
│ Serveurs │
│INJOIGNABLES│
└────────────┘Pourquoi c’est arrivé ?
1. La panne silencieuse
Le switch qfx32.pa2.par présentait un défaut rare mais critique :
| Comportement | État |
|---|---|
| Ports physiques | ✅ UP (LED allumées) |
| Console RS232 | ❌ Aucune réponse |
| Adresses IP | ❌ Aucune réponse |
| Transit trafic | ❌ Aucun |
| Détection par les voisins | ❌ Invisible |
2. Le split-brain VRRP
core01 core02
┌───────────┐ ┌───────────┐
│ VRRP │ │ VRRP │
│ MASTER │ ◄── Conflit ──► │ MASTER │
│ (croit) │ │ (croit) │
└───────────┘ └───────────┘
│ │
└──────────┬───────────────────┘
│
Les DEUX routeurs
sont "master"
en même tempsNormalement, le VRRP fait qu’un seul routeur est master. Ici, comme aucune interface physique n’est tombée (les ports du QFX étaient restés UP), le mécanisme de bascule ne s’est jamais déclenché.
3. Le blackholing
core02 reçoit du trafic
│
▼
core02 cherche une route
│
▼
Route trouvée via qfx32
│
▼
qfx32 ne transite plus
│
▼
💀 Trafic jeté dans le videLa résolution
Étape 1 : Isoler core02
On a voulu tout rediriger vers core01. Mais problème :
core02
┌──────────────────────────┐
│ │
│ VLAN 1234 ──► qfx32 │ ← On peut couper
│ │
│ VLAN 2345 ──► machines │ ← On NE PEUT PAS couper
│ VLAN 3456 ──► machines │ ← (machines directes)
└──────────────────────────┘Étape 2 : Routes statiques more-specific
# Sur core02.pa2.par
# Créer des routes /32 plus précises que la route générale
# pour rediriger le trafic vers core01
routing-options static route 192.168.1.10/32 next-hop core01.ip
...Les enseignements
Ce qui a bien fonctionné
- ⏱️ Temps de réaction : 6 minutes entre l’alerte et la prise en main
- 👥 Mobilisation de 4 ingénieurs rapidement
- 🏢 Ingénieur sur site en 1h26 (région parisienne)
- 🔧 Résolution par routes statiques (solution temporaire mais élégante)
Ce qui a mal fonctionné
- ❌ Pas de détection de panne silencieuse
- ❌ Lien OSPF/BGP entre core01 et core02 inactif depuis le 11/03/2026
- ❌ VRRP en split-brain (les deux routeurs master)
- ❌ Architecture non réellement redondante
Le mot de la fin
La leçon principale : la redondance ne sert à rien si les mécanismes de bascule ne fonctionnent pas. Un équipement en panne silencieuse est plus dangereux qu’un équipement franchement éteint, car il est invisible aux systèmes censés le compenser.
Merci à Mediactive networks pour leur soutien pour la résolution de l’incident et pour le travail à venir. Notre objectif reste d’offrir à tous nos clients (mutualisé, infogéré, cloud) un service de qualité, stable et résilient.