Une architecture DDoS multi-upstream combine plusieurs transitaires, politiques BGP et couches de mitigation pour réduire les points de défaillance. Ce guide explique ce que cela résout, et ce que cela ne résout pas seul.
Plusieurs transitaires améliorent la résilience, mais le filtrage doit rester pensé.
Local-pref, communautés, AS path et annonces plus spécifiques contrôlent l’entrée du trafic.
Un design multi-upstream exige monitoring, seuils et procédures de rollback avant la première attaque.
Une architecture DDoS multi-upstream signifie qu’un réseau protégé ne dépend pas d’un seul transitaire, d’une seule politique BGP ou d’un seul point d’entrée physique. Elle combine plusieurs upstreams, des politiques de routage et des couches de mitigation pour qu’une panne fournisseur, une maintenance, un incident BGP ou un port saturé ne devienne pas immédiatement une panne client. Mais multi-upstream ne veut pas dire automatiquement protégé. Sans logique de filtrage, local-pref clair, politique de préfixes, capacité planifiée et handoff propre, plusieurs upstreams peuvent simplement répartir le même problème sur plus de liens.
Peeryx privilégie un design lisible : capacité amont, filtrage précis, handoff propre et support capable d’expliquer les décisions pendant l’incident.
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.
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 ?
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.
Peeryx traite le multi-upstream comme un sujet de routage et de mitigation ensemble. Le but n’est pas seulement d’ajouter des transitaires, mais de définir le rôle de chacun : transit normal, soulagement d’urgence, enforcement FlowSpec, entrée protégée, backup ou retour de trafic propre.
En pratique, il faut une politique par préfixe et par scénario. Certains préfixes peuvent être annoncés en permanence via transit protégé. D’autres peuvent basculer pendant l’attaque. Certains clients reçoivent le trafic propre par GRE ou cross-connect, d’autres gardent un contrôle BGP. Cette politique doit être visible avant la crise.
La capacité FlowSpec et blackhole est aussi évaluée par upstream. Un fournisseur capable de règles FlowSpec précises peut aider à dé-grossir un flood. Un fournisseur ne proposant que du blackhole reste utile, mais pas au même endroit dans le runbook.
Peeryx privilégie un design lisible : capacité amont, filtrage précis, handoff propre et support capable d’expliquer les décisions pendant l’incident.
Imaginez un petit opérateur avec deux ports 100G chez deux fournisseurs. En temps normal, le trafic est réparti pour le coût et la latence. Un préfixe client reçoit soudainement 120 Gbps d’UDP flood depuis plusieurs régions. Si les deux upstreams acceptent tout sans filtrage, l’opérateur sature simplement deux ports au lieu d’un.
Un meilleur runbook garde l’agrégat visible, mais déplace le plus spécifique attaqué vers le chemin protégé, applique un filtrage amont sur la composante évidente de l’attaque et relivre le trafic propre au client par un handoff contrôlé. Le second upstream reste utile pour le trafic non touché et la redondance.
Le résultat n’est pas un équilibrage magique, c’est du traffic steering volontaire. Les ingénieurs savent quelle route annoncer, quelle communauté poser, quel seuil déclenche l’action et comment revenir à l’état précédent après l’attaque.
Identifier volume, PPS, protocole, ports, chemin BGP et impact client.
Appliquer l’action minimale efficace : route, filtre, bascule ou handoff.
Retirer ou resserrer les règles dès que la pression baisse pour éviter les effets persistants.
Ils améliorent la résilience, mais ne garantissent pas la mitigation. Il faut aussi filtrage, capacité et traffic steering contrôlé.
Pas toujours. Certains préfixes doivent utiliser une entrée protégée, d’autres du transit normal, et certains seulement des plus spécifiques pendant incident.
Il peut le faire si la politique BGP et la qualité des upstreams sont bonnes. Il peut aussi empirer les chemins sans monitoring.
Oui. Le client peut garder ses transitaires et utiliser Peeryx pour l’entrée protégée, le handoff propre ou les scénarios DDoS.
La protection DDoS multi-upstream est puissante seulement si elle est pensée comme une politique, pas comme une liste de fournisseurs. L’architecture doit dire quel upstream attire, lequel filtre, lequel porte le backup et comment le trafic propre revient.
Le meilleur setup combine diversité fournisseur, sécurité de routage, filtrage DDoS et runbooks d’exploitation. Sans cela, plusieurs upstreams multiplient la complexité. Avec cela, ils deviennent un vrai avantage de résilience.
Peeryx peut analyser vos préfixes, vos upstreams, vos contraintes de latence et votre exposition DDoS afin de proposer un modèle de transit protégé ou de handoff propre adapté à votre vraie topologie.
