Sur cette page
À retenir
- Décrire le servicePréfixes, protocoles, pointes normales et contraintes d’exploitation rendent les devis comparables.
- Distinguer les capacitésTransport, traitement des paquets et connexion livrée constituent des limites différentes.
- Préparer la recetteConvenez des observations, des scénarios de panne et des responsabilités de reprise avant l’activation.
Présenter les mêmes besoins à chaque fournisseur
Une demande utile commence par le service à maintenir disponible. Indiquez les applications, les familles d’adresses, les préfixes ou points d’accès publics à protéger, le trafic en heure chargée et la provenance des utilisateurs. Précisez si vous gérez un ASN et des préfixes, si le routage peut changer et qui exploite le serveur final. Le fournisseur pourra distinguer protection réseau, proxy propre à un protocole et logiciel de filtrage sur vos équipements.
Gardez le premier échange court. Pour une première étude, donnez le type de service, le trafic approximatif, les contraintes de livraison et un contact. La politique de routage détaillée, l’inventaire matériel et les traces d’incident pourront suivre par un canal convenu. Identifiants secrets, clés privées et captures client non expurgées n’ont pas leur place dans un formulaire public.
| Besoin | Informations utiles | Question au fournisseur |
|---|---|---|
| Adressage et routage | ASN, préfixes autorisés, IPv4/IPv6 et fournisseurs actuels. | Que pouvez-vous annoncer, et quelles vérifications précèdent la livraison ? |
| Trafic et applications | Gbit/s et Mpps habituels, comportement des connexions et protocoles nécessaires. | Quelles fonctions couvrent cette charge, et lesquelles ne la couvrent pas ? |
| Livraison | Tunnel ou raccordement physique, localisation et contraintes du chemin retour. | Quels débit, MTU et paramètres de routage s’appliquent à chaque chemin ? |
| Exploitation | Responsables des routeurs, serveurs, mesures et astreintes. | Qui modifie les règles, confirme la reprise et annule un changement défaillant ? |
Associer chaque chiffre de capacité à son périmètre
Une capacité d’absorption réseau partagée n’est pas une réservation sur votre circuit. Un résultat de serveur ne représente pas toutes les configurations sous licence. Une interface 100 Gbit/s ne prouve pas que son hôte traite des paquets minimaux avec les règles proposées. Demandez où la mesure a été prise, dans quel sens, avec quel trafic, et si la limite est physique, liée à la licence, partagée ou contractuelle.
Lorsqu’une offre annonce un débit, demandez la convention de taille des trames, le débit en paquets, la répartition du trafic, les fonctions actives, le matériel et la version logicielle. Un résultat de transfert de grandes trames ne qualifie pas le filtrage de petits paquets. La charge CPU moyenne ne décrit pas non plus les performances d’une file de réception isolée. Ces questions servent à comparer, pas à écarter par principe le matériel ou le logiciel.
Dessiner le trafic normal, protégé et de retour
Le schéma doit montrer où le trafic est observé, dirigé, filtré, puis livré au service. Ajoutez le sens retour. Une fonction qui vérifie l’état des connexions peut exiger que les deux sens atteignent le même équipement responsable de l’état, ou un mécanisme de partage pris en charge. Collecteur de routes, contrôleur de diversion et moteur de filtrage en ligne ne sont pas interchangeables.
Pour une livraison redondante, identifiez les routeurs, liens physiques, alimentations et dépendances amont communs. Deux tunnels peuvent avoir des adresses différentes et terminer sur le même routeur. Demandez ce qui se passe lorsqu’une session, une interface ou l’équipement entier tombe. La redondance est qualifiée par le périmètre de panne testé, pas par le nombre de voyants BGP verts.
Rédiger une recette avec le fournisseur
Choisissez des conditions de recette mesurables pour votre application. Une route installée ou un compteur d’attaque qui augmente constitue une observation utile, mais ne prouve pas que les utilisateurs terminent leurs transactions. Relevez les connexions échouées, les temps de réponse et le trafic attendu en parallèle des compteurs de mitigation.
N’effectuez pas de benchmarks de débit perturbateurs sur un réseau de production. La RFC 6815 explique pourquoi les hypothèses des benchmarks RFC 2544 ne conviennent pas à un réseau partagé en service. La recette opérationnelle d’un service actif nécessite une procédure bornée et convenue ; les charges destructrices relèvent d’un environnement séparé.
Valider le fonctionnement normal
Relevez la réussite des opérations applicatives, la latence, les routes sélectionnées et les compteurs avant les changements.
Tester le chemin livré
Vérifiez les familles d’adresses convenues, les échanges petits et grands, le MTU et les deux sens du trafic.
Valider le filtrage en environnement isolé
Convenez du trafic autorisé, des seuils et du comportement légitime attendu dans un environnement de test isolé.
Tester la reprise
Vérifiez le retrait des règles, le transfert par le secours, le retour au chemin préféré et le responsable de chaque action d’annulation.
Lire les modalités d’exploitation autant que les fonctions
Demandez ce que comprend le prix mensuel, ce qui déclenche un dépassement, quelles statistiques sont utilisées et comment la période de facturation est définie. Séparez trafic engagé, débit de l’accès, possibilité de burst, nombre d’adresses protégées, capacité logicielle et assistance en option. Percentile, pointe échantillonnée et vitesse de port décrivent des choses différentes.
Un SLA doit préciser le service couvert, le point de mesure, les exclusions et le recours prévu. Un objectif de délai de réponse du support n’est pas automatiquement une garantie de rétablissement. Demandez le circuit d’escalade, les autorisations pour les filtres d’urgence, la procédure de traitement des faux positifs et les preuves disponibles après incident. Ces éléments doivent figurer dans l’offre ou le contrat réel ; un badge commercial ne les établit pas.
Comparer des modèles de déploiement équivalents
Comparez un service réseau managé avec son périmètre de livraison et d’exploitation ; comparez une licence logicielle avec les serveurs, interfaces, transports et équipes qu’elle nécessite. Le prix d’un composant peut être justifié tout en ne couvrant qu’une partie du chemin. Séparez détection, orchestration, filtrage et capacité réseau dans le tableau pour rendre les éléments manquants visibles.
Chez Peeryx, Transit IP protégé, Defense Fabric et Flow Collector remplissent des fonctions différentes. Defense Fabric fournit une licence de filtrage pour un déploiement compatible ; il n’inclut pas de réservation dédiée de la capacité réseau partagée. Flow Collector observe la télémétrie et peut piloter une diversion autorisée ; ce n’est pas un filtre de paquets en ligne. La livraison Gaming doit être étudiée pour l’application prise en charge.
Consigner les inconnues avant de valider l’achat
Pour chaque besoin, conservez la réponse du fournisseur, le document justificatif, le test de recette et la condition non résolue. Une mesure manquante reste inconnue : ne la transformez pas en estimation de performances. Cela rend le travail d’ingénierie restant visible et facilite la transmission aux équipes après la vente.
Un petit pilote autorisé peut répondre à une question précise de compatibilité. Il ne prouve pas une capacité illimitée, toutes les familles d’attaque ni tous les scénarios de reprise. Reportez les conditions non testées dans la recette de production, au lieu de considérer silencieusement un pilote réussi comme une qualification complète.
Questions avant de signer
Un chiffre en Tbit/s plus élevé est-il toujours préférable ?
Il peut décrire davantage de capacité réseau partagée, sans établir le débit livré, les ressources réservées, la charge en paquets ni la couverture applicative. Comparez ces éléments séparément.
Quelle est la demande initiale minimale utile ?
Indiquez le service, le trafic habituel, les adresses ou le modèle de routage et la principale contrainte de livraison. Ajoutez l’inventaire détaillé après avoir convenu du périmètre initial.
Un essai remplace-t-il une recette technique ?
Non. Un essai valide des conditions définies. Les preuves, les scénarios de panne et les inconnues restantes doivent quand même être consignés.
