Plusieurs transitaires : organiser la résilience sous DDoS

Définition du problème

L’erreur fréquente consiste à considérer un second transitaire comme un produit Anti-DDoS. Ce n’en est pas un. Un deuxième upstream protège contre une panne fournisseur, améliore la joignabilité et apporte de la capacité, mais un gros DDoS peut encore saturer les deux liens si le routage attire le trafic au mauvais endroit.

Pendant une attaque, Internet ne répartit pas automatiquement le trafic de manière utile. Certains réseaux eyeball préfèrent un upstream, d’autres un autre, et une annonce plus spécifique peut écraser un agrégat soigneusement pensé. Si les politiques sont floues, les ingénieurs modifient les routes pendant l’incident sans connaître les effets secondaires.

Le multi-upstream augmente aussi la complexité : prefix-limit, filtres IRR/RPKI, AS-SET, communautés, FlowSpec, blackhole et escalades NOC peuvent varier selon le fournisseur. Le design doit intégrer ces différences au lieu de supposer que tous les transitaires se valent.

Pourquoi c’est important

Pour un hébergeur ou un opérateur, la diversité upstream est un sujet de continuité d’activité. Une panne opérateur ne doit pas couper les clients. Un chemin congestionné ne doit pas rendre un pays injoignable. Un pattern DDoS ne doit pas forcer tout le réseau en blackhole alors qu’un autre chemin de mitigation peut encore porter du trafic propre.

C’est aussi important pour scaler et négocier. Si tous les préfixes protégés dépendent d’un seul contrat, d’un port et d’une équipe support, la croissance devient fragile. Plusieurs upstreams permettent d’augmenter la capacité par étapes, de faire du traffic engineering et de mieux négocier, mais seulement avec un modèle d’exploitation clair.

L’angle DDoS est subtil : la redondance n’est utile que combinée au filtrage et à la visibilité. Sinon, le réseau paie plus de capacité tout en échouant au premier point de saturation. La vraie question est : que se passe-t-il pour ce préfixe, via quel fournisseur, quand ce type d’attaque apparaît ?

Les solutions possibles

Le premier modèle est actif/secours. Un upstream porte le trafic normal et le second sert au failover. C’est simple, mais risqué si le secours n’est jamais testé ou sous-dimensionné.

Le second modèle est le multihoming actif/actif. Le trafic entre par plusieurs fournisseurs. Cela peut améliorer latence et capacité, mais demande local-pref, communautés, route-maps et monitoring précis pour éviter une asymétrie non voulue.

Le troisième modèle combine transit protégé et transit classique. Le chemin protégé attire les préfixes attaqués, tandis que les autres upstreams portent le trafic normal ou non critique. C’est efficace financièrement, mais doit être documenté avant l’incident.

Le quatrième modèle est la livraison multi-site ou anycast. Plusieurs PoP annoncent le même service. Cela aide à répartir la charge, mais anycast ne remplace pas le filtrage : il distribue le trafic, il ne décide pas automatiquement ce qui est légitime.

• Anycast et DDoS : apports et limites ↗

  Comprendre quand anycast aide et quand il ne suffit pas.

Deux ports de 100 Gbit/s : vérifier chaque entrée

Deux ports de 100 Gbit/s représentent 200 Gbit/s de capacité entrante nominale cumulée, sans répartition égale garantie. Une attaque de 120 Gbit/s ne peut pas, à elle seule, remplir simultanément les deux ports à 100 Gbit/s. Elle peut néanmoins saturer un port si, par exemple, 110 Gbit/s suivent un chemin et 10 Gbit/s l’autre.

Le trafic normal, les limites de traitement des paquets et les équipements communs ajoutent d’autres contraintes. Mesurez chaque port et son débit en paquets : 90 Gbit/s libres sur le second port ne soulagent pas automatiquement le premier. BGP choisit selon les politiques de routage, pas selon la charge instantanée.

La préférence locale sélectionne principalement votre chemin sortant. Le trafic entrant dépend des annonces acceptées et préférées par les réseaux distants, ainsi que des communautés prises en charge par les transitaires. Validez les autorisations des préfixes, la propagation et la livraison avant de compter sur un chemin de secours protégé.

Erreurs fréquentes

• Acheter plusieurs upstreams mais utiliser la même politique partout.
• Croire que BGP équilibre intelligemment le trafic d’attaque tout seul.
• Ne pas tester la capacité de backup avant un vrai incident.
• Ignorer RPKI, IRR et les filtres de préfixes chez les nouveaux transitaires.
• Mélanger chemins protégés et non protégés sans documenter quel préfixe utilise quel modèle.
• Accepter des comportements blackhole ou FlowSpec différents sans runbook.

FAQ