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ésolu
L’architecture (simplifiée)
Avant l’incident
INTERNET
│
│ BGP
│
┌────────────┴────────────┐
│ │
┌─────┴─────┐ ┌──────┴─────┐
│ core01 │ OSPF/ │ core02 │
│ EX │◄──BGP────► │ EX │
│ │ (inactif) │ │
└─────┬─────┘ └──────┬─────┘
│ │
│ │
┌─────┴─────────────────────────┴─────┐
│ qfx32.pa2.par │
│ (QFX) │
│ ✅ 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 │
└─────────────────┬───────────────────┘
│
💀 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 |
Point clé : Les équipements voisins voyaient
toujours des ports actifs. Aucun mécanisme n’a signalé la
défaillance.
2. Le split-brain VRRP
core01 core02
┌───────────┐ ┌───────────┐
│ VRRP │ │ VRRP │
│ MASTER │ ◄── Conflit ──► │ MASTER │
│ (croit) │ │ (croit) │
└───────────┘ └───────────┘
│ │
└──────────┬───────────────────┘
│
Les DEUX routeurs
sont "master"
en même temps
Normalement, 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 vide
La 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 ...
Principe : Une route plus précise (/32) est toujours
prioritaire sur une route générale (/24). Cela permet de rediriger le
trafic des machines impactées vers core01 sans toucher
aux machines connectées directement à core02.
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
Actions correctives
| Priorité | Action | Statut |
|---|---|---|
| 🔴 Haute | Réactiver le lien OSPF/BGP intra-core | À faire |
| 🔴 Haute | Implémenter des health-checks sur les interfaces physiques | À faire |
| 🟡 Moyenne | Auditer la configuration VRRP | À faire |
| 🟡 Moyenne | Documenter les dépendances machines / core02 | À faire |
| 🟢 Basse | Révision complète de l’architecture réseau | À planifier |
Le mot de la fin
« Il n’existe pas de correctif simple en l’état. Rendre l’ensemble
réellement résistant à la panne d’un équipement passerait par une
révision de l’architecture, pour la simplifier et la rendre plus
cohérente. »
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.