Le peering et le transit IP ne se comportent pas de la même manière sous pression DDoS. Ce guide explique les différences de routage, capacité, coûts et exploitation pour les réseaux protégés.
Il peut réduire coût et latence vers certains réseaux, mais ce n’est pas une couverture Internet globale.
Un transitaire offre une joignabilité plus large et souvent plus de contrôles liés au DDoS.
Un trafic entrant bon marché ne l’est plus s’il sature un port et contourne la mitigation.
Le peering et le transit sont souvent comparés sur le coût ou la latence, mais le DDoS change complètement la lecture. Le peering est une interconnexion directe entre réseaux, souvent utilisée pour échanger du trafic avec des partenaires ou via un point d’échange. Le transit est une joignabilité payante vers Internet via un fournisseur upstream. En temps normal, les deux sont utiles. Pendant une attaque, la vraie question devient opérationnelle : qui absorbe le flood, qui peut filtrer, qui peut blackholer ou appliquer FlowSpec, et quel chemin relivre encore du trafic propre aux utilisateurs ?
Peeryx privilégie un design lisible : capacité amont, filtrage précis, handoff propre et support capable d’expliquer les décisions pendant l’incident.
Le problème est que le peering peut attirer du trafic sans offrir le même modèle de service qu’un transit protégé. Une session de peering public peut donner une excellente latence vers un gros FAI, mais si un flood arrive par ce port et qu’il n’existe pas de chemin de mitigation, le chemin le plus court devient le chemin de panne.
Le transit, de son côté, n’est pas automatiquement propre. Un transitaire classique peut fournir full routes et reachability mondiale, mais s’il ne propose qu’un blackhole basique, le service protégé a encore besoin d’une autre couche. La vraie question n’est pas “peering ou transit ?”, mais “quel chemin a la capacité, le filtrage, le support et le handoff contrôlé pendant l’attaque ?”
Le DDoS interagit aussi avec la politique BGP. Une route plus spécifique, un changement d’AS path ou une communauté peut déplacer le trafic du peering vers un transit protégé. Mais si cette politique est improvisée pendant l’incident, elle peut créer asymétrie, mauvais chemins retour ou coût inattendu.
C’est important parce que beaucoup de réseaux optimisent d’abord le trafic normal : commit transit plus bas, plus de peering, trafic entrant moins cher, chemins plus courts. C’est logique, mais le DDoS n’est pas du trafic normal. Il peut arriver par le chemin le moins cher, le plus rapide ou le moins préparé.
Pour un serveur de jeu, une plateforme SaaS, du streaming ou de l’hébergement, une décision de peering peut devenir un sujet support. Les utilisateurs disent “le serveur est down” alors que la cause réelle est une entrée régionale via un point d’échange saturé. Sans visibilité par ingress, l’opérateur accuse le mauvais firewall, serveur ou logiciel.
Le transit fait aussi partie d’une promesse commerciale. Un transit protégé doit expliquer filtrage, alternatives au blackhole, options FlowSpec, limites de capacité et livraison de trafic propre. Un pair public ne fournit généralement pas ce niveau de service DDoS spécifique au client.
Une solution consiste à garder le peering pour le trafic normal faible latence, mais à router les préfixes attaqués par le transit protégé. On garde l’avantage performance tout en donnant un vrai chemin de mitigation aux ingénieurs.
Une autre solution est la dé-préférence sélective : pendant l’attaque, des communautés ou route-maps rendent certains chemins moins attractifs sans retirer le service. Cela demande des tests et du monitoring.
Une troisième option consiste à conserver le peering public, mais avec suffisamment de capacité et de filtrage sur l’edge IXP : ACL, sampling, FlowSpec interne et escalade claire auprès du peer ou de l’IXP quand l’abus est visible.
Enfin, certains services doivent simplement utiliser le transit protégé comme chemin entrant principal. Si la disponibilité sous attaque compte plus que quelques millisecondes ou quelques euros, il vaut mieux concevoir la protection d’abord et optimiser le peering ensuite.
Peeryx positionne le transit IP protégé comme le chemin qui doit rester compréhensible pendant l’attaque. Le peering peut rester utile, mais le chemin protégé doit avoir un rôle défini : attirer, filtrer et relivrer le trafic propre sans laisser le client deviner ce qui se passe.
L’approche consiste à cartographier les chemins d’entrée par préfixe et par service. Certains flux peuvent passer sans risque par peering. D’autres doivent entrer en permanence par mitigation. D’autres peuvent basculer uniquement lorsque des seuils sont dépassés. Le but est d’éviter les trous de protection où un service attaqué entre par un port de peering non protégé.
Pour les réseaux utilisant BGP, Peeryx peut travailler avec politiques de route, tunnels, cross-connects ou sessions BGP client afin de garder du contrôle tout en bénéficiant d’une couche construite pour les conditions DDoS.
Peeryx privilégie un design lisible : capacité amont, filtrage précis, handoff propre et support capable d’expliquer les décisions pendant l’incident.
Un fournisseur gaming peer sur un IXP pour une faible latence vers un gros FAI et achète du transit chez deux upstreams. En temps normal, les métriques sont excellentes. Puis les attaquants ciblent le port de query du jeu depuis l’empreinte de ce même FAI. Le trafic entre par peering car le chemin est préféré et sature le port IXP.
La réaction rapide mais mauvaise est de couper la session de peering. Cela peut restaurer la stabilité, mais augmente la latence pour tous les utilisateurs de ce FAI. Un meilleur design déplace seulement le préfixe ou service attaqué vers le transit protégé, applique un filtrage ciblé et garde le reste du peering actif lorsqu’il reste sain.
Après l’incident, l’opérateur compare latence, perte, volume ingress et faux positifs. Ce retour permet de décider si le service reste sur transit protégé, revient au peering ou utilise une politique hybride.
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.
Non. Il peut être excellent, mais il ne doit pas contourner la mitigation des services qui ont besoin d’être protégés.
Pas automatiquement. Un transit protégé avec filtrage et handoff propre est différent d’un transit classique avec blackhole seulement.
Oui. Beaucoup de designs solides gardent le peering pour le trafic normal et utilisent le transit protégé pour les préfixes attaqués ou critiques.
Souvent vers certains réseaux. Mais si le chemin peering sature sous attaque, l’expérience réelle devient pire qu’un chemin protégé légèrement plus long.
Peering vs transit n’est pas un débat religieux. Le peering optimise des chemins choisis ; le transit donne une joignabilité plus large ; le transit protégé ajoute un rôle opérationnel de mitigation. Sous DDoS, le meilleur chemin est celui qui reste disponible, observable et contrôlable.
Un design sérieux définit quels services peuvent utiliser le peering, lesquels doivent entrer par transit protégé et comment la politique BGP change pendant un incident. C’est ainsi qu’un réseau garde les gains de latence sans transformer le peering en porte d’entrée non protégée.
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.
