Résumé
- InterEdge B.V. possède une identité néerlandaise attribuable, deux systèmes autonomes clairement nommés, des produits de transit et d'interconnexion publics, des enregistrements actuels chez RIPE et PeeringDB, un looking glass, des contrôles de routage publiés, des contacts NOC et abus nommés, et des conditions de service régies par le droit néerlandais.
- Ces enregistrements rendent l'entreprise évaluable, mais ils ne prouvent pas indépendamment la disponibilité annoncée, le nombre de pairs, la qualité des routes, la profondeur des effectifs, les temps de réponse, la localité complète du trafic ou les performances de rétablissement. Les acheteurs ont toujours besoin d'un périmètre de service signé, d'un test d'acceptation et d'un plan de sortie.
L'edge est une chaîne d'enregistrements
Un service réseau devient précieux au moment où personne ne veut y penser: lorsqu'un site distant s'ouvre, qu'une plateforme de contenu explose, qu'une route cloud change ou qu'un opérateur primaire abandonne une session. À ce moment-là, le client n'a pas besoin d'une promesse générale de connectivité mondiale. Il doit savoir quelle entreprise a accepté la commande, quel système autonome transporte le trafic, quelle remise physique appartient au circuit, quelles routes doivent être présentes, quels filtres sont actifs, qui surveille le port et qui peut annuler une mauvaise modification.
InterEdge B.V. dispose de suffisamment d'enregistrements publics pour mériter une évaluation approfondie. Sa page de contact mentionne une société privée néerlandaise au Krammer 8 à Brielle, en Hollande-Méridionale, donne le numéro d'immatriculation 87355299 et un numéro de TVA néerlandais, et associe l'entreprise aux AS213753 et AS56584. La base de données RIPE relie indépendamment le même nom d'entreprise, le même numéro d'immatriculation et la même adresse à Brielle aux deux systèmes autonomes.
PeeringDB expose les contacts publics d'exploitation réseau, de vente et d'abus, et répertorie les connexions d'échange et les installations actuelles pour AS213753. Un looking glass public identifie un emplacement à Amsterdam. L'entreprise publie également des descriptions de services, des conseils sur les communautés de routage et des conditions régies par le droit néerlandais.
Ce sont des signaux significatifs car ils rendent l'offre attribuable. Ils ne transforment pas chaque déclaration du site web en un résultat observé. Un numéro d'immatriculation établit une identité légale, pas la qualité du service. Un enregistrement de système autonome établit le titulaire d'un identifiant de routage, pas la latence du chemin d'un client. Une entrée PeeringDB enregistre des données d'interconnexion déclarées, pas une disponibilité continue. Une adresse NOC publiée crée un canal, pas un objectif d'accusé de réception. Une page de prix établit une offre à un moment donné, pas le coût total installé.
Cette distinction est particulièrement importante pour InterEdge car l'offre visible couvre plusieurs activités différentes. Le transit IP achemine les routes internet d'un client. Le transport couche 2 étend un domaine Ethernet entre des remises. Inter-IX fournit une structure de peering partagée avec ses propres règles de connexion. Les services IP couvrent la location, le transfert, le DNS inverse, la géolocalisation et la gestion des abus. Le conseil s'étend aux migrations cloud, à Kubernetes, à l'architecture réseau, au travail pratique en centre de données et au personnel temporaire.
Le même nom de fournisseur se trouve au-dessus de produits avec des modes de défaillance et des limites de responsabilité très différents.
La question utile n'est donc pas de savoir si InterEdge est un véritable opérateur réseau néerlandais. Les enregistrements publics soutiennent cette conclusion. La question utile est de savoir si un service particulier d'InterEdge peut être spécifié, testé, surveillé et remplacé avec un risque tolérable. Cela nécessite que l'acheteur sépare l'identité de la performance, la topologie du marketing, l'automatisation de la responsabilité, et une adresse néerlandaise d'un véritable engagement de localité des données.
L'identité de l'entreprise est plus solide que l'histoire d'origine
L'enregistrement corporatif d'InterEdge est exceptionnellement concret pour une marque réseau jeune. La page de contact de l'entreprise donne une adresse physique, un numéro de téléphone, un numéro d'immatriculation, un identifiant TVA, des coordonnées bancaires, une route email et les deux systèmes autonomes. L'objet organisation de RIPE pour InterEdge B.V. répète le numéro d'immatriculation 87355299, l'adresse Krammer 8, le code pays Pays-Bas et un contact abus. L'enregistrement de rôle porte le même numéro de téléphone public que celui affiché par PeeringDB.
Ces identifiants concordants réduisent le risque que l'acheteur ait affaire à une marque flottante qui ne peut être rattachée à une entité contractante.
Les dates dans les registres réseau aident également à délimiter l'historique. RIPE a créé l'objet organisation en août 2022. AS56584, nommé INTER-IX, a été attribué en octobre 2022. AS213753, nommé interedge, a été attribué en décembre 2024. Ce sont des dates pour les objets de registre et les attributions de numéros, pas la preuve que chaque service a commencé ces jours-là. Le pied de page du site indique 2008-2026, mais une plage de droits d'auteur n'est pas un enregistrement d'incorporation et ne doit pas être utilisée comme telle.
Les achats devraient utiliser l'immatriculation néerlandaise de l'entreprise, le contrat signé et les enregistrements de registre actuels comme ancres d'identité.
Le site liste également InterEdge L.L.C. à une adresse du Delaware, utilisant le même site web, la même structure téléphonique, les mêmes coordonnées bancaires et les mêmes systèmes autonomes. Cela peut être utile pour les clients cherchant une voie commerciale américaine, mais cela crée une question contractuelle plutôt que de la résoudre. L'acheteur doit enregistrer quelle entité établit le devis, facture et assume la responsabilité; quelle entité est le sous-traitant de données lorsque le conseil ou les données de compte sont impliqués; et quelle loi et quel tribunal sont compétents.
Les conditions publiques sont rédigées pour InterEdge B.V. et renvoient au droit néerlandais et au tribunal compétent d'Amsterdam. Un client contractant avec une autre entité ne doit pas supposer que ces dispositions sont transférées inchangées.
Il y a une autre raison de maintenir l'alignement des identités légale et réseau. L'espace d'adressage, les sessions BGP, les cross-connects et les adhésions aux échanges Internet impliquent souvent des enregistrements différents. Un devis peut utiliser une marque commerciale, une lettre d'autorisation peut identifier un titulaire d'adresse, un objet route peut identifier un mainteneur, et le cross-connect physique peut être commandé via un compte de centre de données. Si ces noms divergent, un changement de routine peut stagner pendant que chaque fournisseur attend l'autorisation d'une autre partie.
L'enregistrement de service doit donc contenir l'entité contractante, l'ASN, l'autorité IRR ou RPKI, le compte d'installation, l'identifiant de port, le contact de facturation, le contact NOC et la route d'abus.
Les enregistrements publics concordants d'InterEdge réduisent ce risque administratif, mais ne l'éliminent pas. Le site propose la location IPv4 et les transferts inter-registres ainsi que le transit. Dans ce métier, la partie qui détient une ressource, celle qui l'annonce, celle qui la loue et celle qui la paie peuvent ne pas être les mêmes. Un client doit exiger que les documents commerciaux précisent qui peut annoncer chaque préfixe, qui crée les autorisations de route, qui met à jour le DNS inverse et la géolocalisation, qui reçoit les notifications d'abus, et ce qu'il advient de ces enregistrements à la fin de l'accord.
L'identité est donc la partie la plus solide du dossier public. InterEdge B.V. peut être nommée, localisée et connectée à des enregistrements réseau en direct. Le travail restant est de s'assurer que la même précision atteint le service acheté.
Un nom de fournisseur, cinq surfaces opérationnelles
L'expression "services edge" peut cacher plus qu'elle ne révèle. Les propres pages d'InterEdge sont plus claires lorsqu'on les lit produit par produit. Le service commercial principal est le transit IP. L'entreprise annonce des handoffs BGP IPv4 et IPv6, des VLAN dédiés, un filtrage automatique des préfixes, des options de route par défaut ou de table complète,une facturation forfaitaire ou au 95e percentile et des contrats mensuels sur une gamme de capacités engagées. La page précise que les frais de cross-connect et de transport sont exclus et publie un tarif de dépassement.
Ce dernier détail est important: le prix attractif du port n'est pas le même que le coût mensuel total de livraison du trafic jusqu'au rack, au bureau ou au cloud on-ramp du client.
Le transport couche 2 est un produit distinct. InterEdge décrit Ethernet point à point à travers ses points de présence européens, avec un VLAN dédié par circuit, des jumbo frames, un plan de contrôle EVPN avec un plan de données VXLAN, et QinQ pour préserver les tags VLAN du client. La page cadre le service autour d'Amsterdam et Paris et nomme des applications telles que l'interconnexion de centres de données, la connectivité cloud, la réplication de stockage et les plateformes à faible latence.
Ces affirmations définissent un produit technique plausible, mais le client a toujours besoin des emplacements A et Z exacts, du chemin protégé ou non, de l'unité de transmission maximale, du profil de bande passante, de la norme de diversité et des points de délimitation de panne dans la commande.
Inter-IX est encore différent. La page d'échange annonce des ports gratuits à plusieurs capacités et une option distante payante via GRE. La page juridique est plus utile que le langage promotionnel car elle explique à quoi sert la structure gratuite. Les entités doivent utiliser un ASN public et BGP attribué, respecter les adresses de peering attribuées, utiliser une seule source MAC par port, supprimer le trafic link-local prohibé, enregistrer les routes annoncées et éviter d'utiliser l'échange comme transit ou backhaul non autorisé. L'accès gratuit n'est pas un transport illimité.
C'est un service de peering partagé avec des limites techniques et commerciales spécifiques.
L'offre de services IP va au-delà du transport. InterEdge décrit la location IPv4, la gestion des adresses IPv4 et IPv6, le travail DNS inverse, les mises à jour de géolocalisation, la surveillance proactive, la gestion des abus, les transferts entre registres Internet régionaux et les transactions assistées par séquestre. C'est un travail intensif en enregistrements. Un préfixe peut être routable et pourtant commercialement problématique si son enregistrement est obsolète, sa géolocalisation erronée, son autorité DNS inverse floue, sa réputation mauvaise ou une boîte aux lettres d'abus sans suivi.
Pour un client d'adresses, la valeur opérationnelle réside autant dans la qualité de ces enregistrements que dans le bloc d'adresses lui-même.
Le conseil crée la surface de responsabilité la plus large. L'entreprise annonce des migrations cloud, des zones d'atterrissage, du travail Kubernetes et Docker, des services pratiques en centre de données, de l'architecture réseau, du personnel intérimaire et du personnel DevOps. Dans ces engagements, InterEdge peut concevoir ou modifier les propres systèmes du client plutôt que de transporter des paquets via un service InterEdge. Le client doit définir les droits d'accès, l'approbation des modifications, la propriété du code, la gestion des identifiants, la documentation, l'acceptation, le rollback et la fin de l'accès privilégié.
Un bon fournisseur de transit ne devient pas automatiquement un bon partenaire de migration, et un consultant compétent ne crée pas automatiquement un service managé.
Ces produits peuvent se renforcer mutuellement. Un client pourrait utiliser le transit InterEdge dans une installation néerlandaise, un port Inter-IX pour le peering local, un circuit couche 2 vers un autre site, des adresses louées pour un déploiement temporaire et de l'aide en conseil pour configurer BGP. Ce bundle peut réduire le nombre de fournisseurs. Il peut aussi concentrer le support, la facturation et l'autorité de changement dans une seule organisation. L'évaluation commerciale doit modéliser les deux résultats.
La première discipline d'achat est donc de nommer le service avec précision. "Connectivité InterEdge" n'est pas un objet testable. "Un port de transit BGP dual-stack avec un engagement déclaré dans une installation nommée, une politique de routage convenue, un niveau de service défini et un processus d'annulation documenté" est testable. De même, "un circuit couche 2 protégé entre deux points de délimitation nommés avec une MTU déclarée et un objectif de rétablissement" est testable. Plus la frontière du produit est exacte, plus il devient facile de juger les preuves publiques sans leur accorder des pouvoirs qu'elles n'ont pas.
Deux systèmes autonomes ne doivent pas être traités comme un seul
Les deux ASN sur la page de contact d'InterEdge représentent des rôles opérationnels différents. AS213753 est l'ASN actuel des services réseau d'InterEdge. Son objet RIPE nomme InterEdge B.V., énumère les politiques d'importation et d'exportation pour Hurricane Electric, GTT et Cogent, et renvoie à l'ensemble AS213753:AS-INTEREDGE. PeeringDB le classe comme entreprise et services réseau, enregistre le support IPv4 et IPv6, et expose sa présence d'échange et d'installation. Les pages de transit, de couche 2 et de réseau sont systématiquement centrées sur cet ASN.
AS56584 est nommé INTER-IX. RIPE le lie également à InterEdge B.V., mais le numéro appartient au contexte d'échange. Les conditions légales d'InterEdge appellent explicitement Inter-IX AS56584 et séparent la participation à l'échange du transit InterEdge. Cela importe opérationnellement. Une route vue sur un chemin de transit InterEdge, une session route-server sur un échange, et une session de peering bilatérale d'un membre ne sont pas des preuves interchangeables. Chacune a un propriétaire de politique et un domaine de panne différents.
La distinction est facile à perdre car les deux identifiants apparaissent sur la même page de contact et le fournisseur opère l'échange. Un acheteur devrait la préserver dans les diagrammes et les enregistrements d'incidents. Le bord du transit devrait montrer AS213753, l'ASN du client, les chemins amont ou pairs et le handoff de transit commercial. Le bord de l'échange devrait montrer la structure Inter-IX, les route-servers si utilisés, l'adresse d'échange du client et toutes sessions bilatérales. Un circuit couche 2 devrait être montré comme transport, pas comme une relation de système autonome.
Garder ces rôles séparés améliore le diagnostic des incidents. Si la session BGP d'un client vers AS213753 tombe, la panne pourrait être le cross-connect, le routeur du client, le port de transit ou le edge d'InterEdge. Si une session route-server sur Inter-IX tombe alors que la session de transit reste saine, la panne est plus étroite. Si les deux tombent dans une installation, le handoff physique partagé ou le site peut être la cause commune. Si un échange distant via GRE tombe, le sous-réseau peut être sain tandis que le tunnel ou la session d'échange ne l'est pas.
Un tableau de bord unique étiqueté "InterEdge" peut brouiller tous ces états.
Cela améliore également l'interprétation du contrat. Les conditions Inter-IX interdisent le transit non autorisé sur la structure partagée et autorisent la surveillance et l'application. C'est une politique de protection des entités à l'échange. Elle ne doit pas être confondue avec la politique de transit achetée du client. Inversement, un port d'échange gratuit ne remplace pas un contrat de transit simplement parce que les deux atteignent d'autres réseaux. Le peering sans règlement atteint les pairs consentants et les routes annoncées; le transit est acheté pour atteindre l'internet plus large sous une obligation commerciale différente.
Les enregistrements publics sont suffisamment solides pour montrer qu'InterEdge comprend cette séparation. La tâche de l'acheteur est de la conserver à travers la commande, l'automatisation et le rétablissement. Chaque session doit avoir un propriétaire, un but, un ASN distant, une famille d'adresses, un paramètre de maximum de préfixes, une politique d'authentification, une référence de politique de routage et un chemin d'escalade. Le nom du fournisseur peut être partagé. Les contrôles ne peuvent pas.
Les enregistrements réseau révèlent la portée, pas l'expérience
AS213753 a une empreinte publique visible et récemment mise à jour. L'enregistrement PeeringDB de juin 2026 liste quatre connexions d'échange: INTERIX, Frys-IX, Speed-IX et nine. Les capacités déclarées vont d'un port Speed-IX plus petit à des connexions plus grandes Frys-IX, nine et INTERIX. Il liste également dix-neuf installations, principalement aux Pays-Bas, avec des enregistrements supplémentaires à Paris et dans la région de Francfort. Les entrées néerlandaises incluent Nikhef, plusieurs sites Equinix Amsterdam, Bytesnet Rotterdam, ColoCenter Zoetermeer, une installation à La Haye, des emplacements Greenhouse et des sites Qupra.
La page réseau de l'entreprise concorde globalement avec la forme de l'empreinte. Elle nomme des sites néerlandais, Paris et d'autres emplacements, indique que le réseau utilise des routeurs Juniper et des commutateurs Arista, et identifie plusieurs relations d'échange et d'amont. Ses compteurs en direct indiquent six transporteurs de transit, plus de 1 791 peering privés et plus de quinze centres de données connectés. La page "À propos", cependant, indique plus de 1 400 peering directs. PeeringDB donne un type de comptage différent: quatre connexions d'échange publiques et dix-neuf enregistrements d'installations.
BGP.tools expose un grand AS-set et un ensemble de connexions d'échange observées.
Ces chiffres ne doivent pas être forcés en un seul nombre. "Peering privés", "pairs directs", membres d'AS-set, entités route-server, présence dans les installations et ports d'échange mesurent des choses différentes. Ils peuvent également être mis à jour à des moments différents. Un acheteur doit demander la définition et la date d'observation derrière tout nombre utilisé dans une proposition. Pour la résilience, la preuve la plus importante est le chemin exact et la politique disponible pour ce client, pas le total des pairs en titre du réseau.
L'enregistrement RIPE actuel d'AS213753 nomme trois politiques d'amont: AS6939, AS3257 et AS174. La page réseau du site nomme en plus RETN et Arelion parmi ses fournisseurs d'amont. Cette différence n'est pas la preuve que l'un ou l'autre enregistrement est erroné. Certaines relations peuvent ne pas être exprimées dans une simple déclaration d'importation publique, et les pages web peuvent décrire un mélange plus large que ce qu'une observation donnée voit. C'est néanmoins une raison pour ne pas reproduire une liste de fournisseurs comme si chaque transporteur était actif à chaque point de présence.
L'acheteur doit demander une conception spécifique à l'emplacement. Quels amonts sont actifs sur le site commandé? Lesquels sont physiquement divers? Le port du client atteint-il un routeur ou deux? Les ports redondants sont-ils sur différentes cartes ligne, châssis, alimentations et chemins de fibre? Le chemin couche 2 est-il protégé, et quel événement déclenche la commutation? Un client recevant la table complète a-t-il la même politique sur les deux sessions? Les routes apprises des échanges sont-elles préférées au transit? Quelles communautés permettent au client d'influencer la propagation, et lesquelles sont réservées au fournisseur?
Les observations publiques de routage offrent un autre signal délimité. Une observation RIPEstat de juillet 2026 montrait AS213753 annonçant deux préfixes IPv4 et un préfixe IPv6 avec une visibilité normale pendant l'intervalle observé. L'une des annonces IPv4 avait une autorisation RPKI valide pour AS213753. Cela soutient l'existence d'un système de routage actif et d'au moins une origine correctement autorisée. Cela ne prouve pas que tous les préfixes clients sont autorisés, que chaque route est acceptée correctement, ou que les annonces invalides seraient toujours rejetées sur tous les chemins.
Le looking glass ajoute une valeur pratique car il donne aux clients une vue depuis Amsterdam. Un test précontractuel utile peut comparer ce que le looking glass voit avec ce que le routeur du client reçoit. Mais un looking glass est un point d'observation, pas une garantie de disponibilité. Il peut se trouver derrière une interface web, n'exposer que des routeurs sélectionnés et omettre les détails de politique. Il devrait compléter les collecteurs de routes, la télémétrie du client et les tickets du fournisseur, pas les remplacer.
L'enregistrement réseau public répond donc bien à une question: InterEdge B.V. exploite une surface de routage et d'interconnexion visible avec des enregistrements à jour dans l'écosystème néerlandais et européen proche. Il ne répond que partiellement à une question plus exigeante: comment le trafic d'un client particulier se comportera en cas de panne. Cette deuxième réponse doit venir de la conception, du contrat et du test d'acceptation.
L'automatisation du routage n'est utile que lorsque la documentation est cohérente
Le modèle opérationnel d'InterEdge dépend fortement de l'automatisation. La page de transit annonce un filtrage automatique des préfixes. Les pages réseau et de transit décrivent la validation RPKI. La page des communautés BGP donne aux clients des étiquettes pour contrôler la publicité amont et le blackholing. Les conditions légales pour Inter-IX décrivent l'enregistrement des routes, les filtres IRR et RPKI, les contrôles des route-servers, les règles de one-MAC, les types de trames autorisés, la suppression link-local et l'échantillonnage de flux.
Ce sont les mécanismes qui permettent à un réseau de prendre des décisions répétées sans demander à un ingénieur de revoir chaque route ou trame manuellement.
Le bénéfice est réel. Les filtres de préfixes peuvent empêcher une annonce large accidentelle. La validation d'origine RPKI peut distinguer une origine autorisée d'une origine invalide. Les contrôles de maximum de préfixes peuvent empêcher une session d'inonder un routeur. Les communautés BGP peuvent permettre à un client de supprimer ou de prepend les annonces vers des amonts sélectionnés. Le blackholing déclenché à distance peut écarter le trafic d'attaque avant qu'il ne consomme un lien contraint. Les contrôles de port d'échange peuvent contenir les erreurs qui affecteraient autrement une structure partagée.
Chaque mécanisme crée également un chemin de défaillance. Un objet IRR obsolète peut faire filtrer une route légitime. Une autorisation d'origine de route expirée ou incorrecte peut transformer un changement commercial valide en une route invalide. Une valeur de maximum de préfixes peut être fixée en dessous de la croissance normale d'un client. Un blackhole large peut supprimer le bon trafic avec le mauvais. Une communauté peut être mal typée, interprétée différemment chez un autre fournisseur ou supprimée à travers une frontière.
L'automatisation réduit le travail de routine en rendant les décisions cohérentes, mais la cohérence est dangereuse lorsque l'enregistrement d'entrée est erroné.
La documentation BGP publique d'InterEdge contient un exemple petit mais important. La page des communautés BGP liste la valeur de blackhole avec213357comme premier nombre, tandis que les communautés de contrôle d'amont de la même page utilisent213753, et l'enregistrement aut-num actuel de RIPE liste la communauté de blackhole comme213753:0:666. Un seul chiffre transposé suffit pour rendre un contrôle d'urgence inefficace ou produire un résultat non désiré si un autre réseau reconnaît la valeur.
La réponse appropriée n'est pas de deviner quelle page les routeurs suivent. Un client prévoyant d'utiliser le blackholing doit obtenir la spécification technique actuelle du NOC, la valider sur un préfixe de test contrôlé et conserver la valeur confirmée avec une date d'effet. La même vérification devrait couvrir les formats de communauté standard et large, le comportement du route-server, les longueurs de préfixe acceptées, la politique RPKI, la source IRR, les limites de maximum de préfixes, le traitement de la route par défaut et ce qui se produit lorsque les données de validation ne peuvent pas être récupérées.
Ce désaccord de documentation est également un test utile de la responsabilité du support. Une question précise devrait produire une réponse précise: quelle communauté est implémentée sur le edge concerné, comment est-elle propagée, quelle action de rejet se produit, peut-elle être appliquée par préfixe et famille d'adresses, et comment la récupération est-elle vérifiée? La réponse devrait être inscrite dans l'enregistrement de service plutôt que laissée dans une chaîne d'emails qui disparaît lorsque le personnel change.
L'automatisation du routage doit ensuite être testée comme un logiciel. Annoncez un préfixe de test autorisé et confirmez l'acceptation. Retirez-le et mesurez la convergence. Créez une origine intentionnellement invalide dans un laboratoire ou une fenêtre de maintenance convenue et confirmez la politique attendue sans mettre en danger le trafic en direct. Exercez chaque communauté de contrôle d'amont approuvée. Testez le comportement d'avertissement et d'arrêt du maximum de préfixes. Vérifiez séparément IPv4 et IPv6. Confirmez si BFD est disponible et quels temporisateurs sont supportés.
Comparez les routes reçues du client avec le looking glass et un collecteur de routes indépendant.
L'objectif n'est pas de défier le fournisseur avec des cas exotiques. C'est de remplacer les hypothèses par des observations avant un incident réel. InterEdge publie suffisamment de surface technique pour rendre un tel test possible. Le client devrait l'utiliser.
La couche 2 modifie le domaine de panne
L'offre couche 2 d'InterEdge mérite un examen séparé car la simplicité Ethernet peut être trompeuse. Un VLAN dédié entre Amsterdam et Paris peut ressembler pour un client à un long câble. En dessous, le fournisseur décrit un overlay EVPN et VXLAN, avec un apprentissage MAC et IP évolutif et une séparation multi-locataire. Il supporte également les jumbo frames et QinQ. Ce sont des outils standard pour construire un Ethernet de transport flexible, mais chacun introduit un état que le client et le fournisseur doivent comprendre.
Un plan de contrôle EVPN distribue des informations d'accessibilité. VXLAN transporte les trames à travers un underlay routé. QinQ imbrique les tags du client dans un tag de service. Les jumbo frames augmentent la charge utile pouvant traverser le chemin. Une panne peut donc se produire dans le circuit physique, le routage de l'underlay, le point de terminaison du tunnel, l'état EVPN, le mappage VLAN, la gestion des tags, l'unité de transmission maximale ou le dispositif du client. Un simple voyant lumineux de liaison ne prouve pas que le service complet est sain.
Le plan d'acceptation devrait commencer à la délimitation. Enregistrez le port du fournisseur, le port du client, les optiques, la vitesse et le duplex, les tags VLAN, le comportement MAC attendu et l'unité de transmission maximale. Testez les trames de taille normale et maximale avec le surdébit correct. Vérifiez que les tags du client survivent là où QinQ est commandé. Confirmez que les VLAN inattendus sont bloqués. Mesurez la perte de trames unidirectionnelles, la latence et la gigue dans les deux directions. Testez les mouvements MAC et le basculement sans créer de boucle.
Si un routage diversifié est acheté, vérifiez que les deux chemins ne partagent pas un segment physique non enregistré.
La réplication de stockage et le mouvement de machines virtuelles méritent une prudence particulière. La page de service nomme ces applications comme bénéficiant des plus grandes trames. Cela ne signifie pas que chaque charge de travail de stockage peut tolérer la latence, le profil de perte ou le mode de défaillance disponibles. La réplication synchrone a un budget aller-retour plus strict que le transfert asynchrone. Un domaine couche 2 divisé peut également étendre la diffusion, la défaillance et les frontières de sécurité entre les sites.
Le client doit décider si l'extension du même réseau est réellement nécessaire ou si une conception routée contiendrait mieux les pannes.
La commande commerciale doit préciser si le circuit est protégé ou non, comment la capacité est engagée et plafonnée, si le dépassement est autorisé, comment le dépassement est mesuré, quelles notifications de maintenance s'appliquent et quel niveau de service couvre le chemin. La page publique mentionne une surveillance de qualité opérateur et des chemins protégés dans son positionnement, mais un client ne doit pas supposer que l'une ou l'autre fonctionnalité est incluse dans chaque forfait listé. La commande signée et la conception technique doivent régler cela.
La couche 2 peut être un complément solide au transit et à la présence en installation d'InterEdge. Elle peut aussi créer une dépendance partagée. Si les deux ports de transit et le circuit inter-site empruntent la même dorsale du fournisseur, un seul événement de plan de contrôle ou de fibre pourrait affecter toute la conception. La résilience peut nécessiter un second fournisseur, un chemin physique différent ou une route internet indépendante sur un site. La consolidation des fournisseurs n'est pratique sur le plan opérationnel que tant que le domaine de défaillance restant est acceptable.
Entreprise locale, réseau régional, localité des paquets incertaine
InterEdge est clairement ancré aux Pays-Bas. Son adresse d'entreprise est à Brielle. Sa liste actuelle d'installations PeeringDB est dominée par Amsterdam, Rotterdam, Zoetermeer, La Haye et Naaldwijk. Son looking glass public montre Amsterdam. Les conditions légales appliquent le droit néerlandais et font référence au RGPD. Pour un acheteur néerlandais, cela crée une proximité utile pour la contractualisation, la facturation et certains travaux sur site.
Cela n'établit pas que tout le trafic client, la télémétrie ou les données de support restent aux Pays-Bas. PeeringDB liste également InterEdge dans une installation à Paris et une dans la région de Francfort. La page couche 2 décrit un service Amsterdam-Paris. Le transit IP est conçu pour échanger du trafic avec des réseaux externes, donc la route vers une destination peut quitter le pays par définition. Même lorsque les deux extrémités sont néerlandaises, la politique BGP et la congestion peuvent modifier le chemin à moins que le service ne soit explicitement conçu pour le maintenir local.
Le site web public illustre une autre couche de dépendance. Dans une observation DNS de juillet 2026, interedge.com utilisait des adresses et des serveurs de noms Cloudflare, tandis que ses enregistrements d'échange de courrier pointaient vers le service de messagerie Google. Cela dit quelque chose sur la porte d'entrée web et email publique de l'entreprise, pas sur le chemin du trafic de transit d'un client. Cela montre néanmoins pourquoi "fournisseur néerlandais" n'est pas une déclaration de localité complète.
Les communications client, les données du portail et les emails de support peuvent toucher des plateformes tierces sous des conditions séparées.
Différents produits InterEdge créent différentes questions de données. Le transit IP transporte les en-têtes et les charges utiles des paquets mais ne stocke normalement pas l'état d'application du client comme le ferait un service d'hébergement. Les conditions Inter-IX indiquent que l'opérateur peut surveiller le trafic de contrôle, les flux échantillonnés, les données de protocole et les informations d'en-tête pour les opérations, la sécurité et la conformité. Les services d'adresses peuvent stocker des enregistrements de déclarant, d'autorisation, de réputation et d'abus.
Le conseil peut exposer les ingénieurs à des consoles cloud, des référentiels de configuration, des identifiants, des journaux et des données d'application. Un engagement pratique en centre de données peut impliquer des enregistrements d'accès physique et des inventaires d'actifs.
Un examen sérieux de la localité doit donc classer les données plutôt que de demander une réponse par pays. Où sont conservés les enregistrements de compte et de facturation? Où les tickets de support et les emails sont-ils traités? Quelle télémétrie de routage et de flux est conservée, pour combien de temps et dans quel but? Quels tiers la reçoivent? À partir de quels emplacements les consultants se connectent-ils, et comment l'accès privilégié est-il enregistré? Quelles installations accueillent le circuit commandé? La maintenance ou le basculement peuvent-ils déplacer le trafic vers un autre pays?
Le client a-t-il besoin de résidence des données, de localité de routage, de localité du support ou des trois?
Les conditions publiques indiquent que les données personnelles sont traitées conformément au RGPD et à une déclaration de confidentialité à l'adresse légale. C'est un engagement de gouvernance, mais ce n'est pas un accord de traitement des données spécifique au client, un calendrier de conservation ou une carte de transfert. Un client réglementé doit obtenir ces documents et identifier les rôles de responsable du traitement et de sous-traitant pour chaque service. Il doit également demander si le fournisseur peut remplir les obligations de suppression, d'accès et d'audit sans perturber les enregistrements de sécurité opérationnelle.
La main-d'œuvre de support locale a une nuance similaire. La page de conseil propose du travail pratique en centre de données et du personnel intérimaire ou DevOps. C'est une preuve plus solide d'une surface de service humain qu'un formulaire de contact générique. Pourtant, les pages publiques n'indiquent pas combien d'ingénieurs sont disponibles dans chaque pays, quelles langues sont couvertes à chaque quart de travail, ou si un site nommé peut recevoir un technicien dans un délai fixe. L'acheteur doit contracter pour la localité qui importe plutôt que de l'inférer du siège social.
L'identité néerlandaise d'InterEdge est utile commercialement. Son réseau est régional et interconnecté par conception. Ces faits doivent être enregistrés séparément pour que ni l'un ni l'autre ne soit confondu avec une garantie concernant chaque paquet, journal ou ingénieur.
Le support est le plan de contrôle que les gens remarquent pendant une panne
InterEdge publie plus de structure de support que de nombreux petits fournisseurs de réseau. PeeringDB liste des routes email distinctes pour le NOC, les ventes et les abus, toutes liées au numéro de téléphone néerlandais. La page de contact invite aux demandes de déploiement de port, de support et de facturation. La page "À propos" indique qu'un support expert est disponible 24 heures sur 24 et décrit des ingénieurs internes. La page de conseil propose du travail pratique, de l'architecture et du personnel.
Le profil professionnel public du fondateur et directeur Desmond van der Winden décrit une longue expérience dans Linux, Windows, hébergement, fibre, BGP, OpenStack, cloud et opérations de centre de données.
Ensemble, ces enregistrements étayent la crédibilité d'une activité technique intégrée, pas simplement externalisée derrière une vitrine. Ils laissent néanmoins sans réponse les questions opérationnelles les plus importantes pour un acheteur. Comment le NOC est-il doté en personnel en dehors des heures de bureau néerlandaises? Le téléphone est-il répondu par un ingénieur, un service de réponse ou un desk d'escalade? Quel est l'objectif d'accusé de réception pour une panne totale? Les abus sont-ils traités par la même équipe d'astreinte? Combien d'incidents simultanés l'équipe peut-elle gérer?
Quels changements nécessitent une approbation supérieure? Quelles visites sur site sont incluses et lesquelles sont facturées séparément?
La déclaration de disponibilité 24/7 du site web doit donc être convertie en une matrice de support. La gravité doit être basée sur l'impact client. Chaque niveau de gravité nécessite un canal autorisé, un objectif d'accusé de réception, un intervalle de mise à jour, un objectif de rétablissement et une échelle d'escalade. Le client doit savoir si un ticket, un email ou un appel téléphonique déclenche le chronomètre et quelles preuves le NOC a besoin.
Pour les incidents de routage, cela inclut généralement l'ASN local et distant, l'adresse de session, les préfixes affectés, l'heure de début, les changements récents, des échantillons de route et des traceroutes dans les deux directions.
La qualité du support dépend aussi de l'autorité. Un ingénieur de première ligne peut voir qu'une session BGP est en panne mais manquer d'accès pour modifier un filtre. Un consultant peut comprendre le cluster Kubernetes du client mais manquer d'autorité sur le edge du transporteur. Un technicien de centre de données peut remplacer une optique mais pas approuver un changement de cross-connect. Le plan d'escalade doit identifier qui peut agir à chaque couche et comment le client autorise un changement d'urgence.
La gestion des abus est particulièrement importante pour l'espace d'adresses loué. Une réponse retardée ou opaque peut endommager la réputation d'un préfixe et créer un blocage bien au-delà d'un incident. Le client doit savoir où arrivent les plaintes, comment les preuves sont partagées, quel délai de réponse s'applique, quand un préfixe peut être suspendu, comment les faux rapports sont contestés et comment la récupération de la réputation est documentée. InterEdge annonce une gestion d'abus de première classe, mais le service mesurable appartient à la commande.
Le conseil augmente le besoin de clarté des rôles. Un ingénieur temporaire peut accélérer la migration et réduire un écart de compétences. Le même ingénieur peut également devenir la seule personne qui comprend une conception. Chaque engagement doit produire des diagrammes appartenant au client, des enregistrements de configuration, des journaux de décision, des étapes de rollback et un transfert d'identifiants. L'accès doit être limité dans le temps et attribuable individuellement. L'acceptation finale doit vérifier que la propre équipe du client peut exploiter le résultat après le départ du consultant.
Le profil professionnel public est un contexte utile, mais il est auto-publié et centré sur une personne. Il n'établit pas la profondeur de l'équipe actuelle. Un acheteur doit demander quel propriétaire de service nommé et quel ingénieur de secours supporteront le compte, puis tester le chemin d'escalade lors de l'intégration. Un fournisseur modeste peut surpasser un grand transporteur lorsque la propriété est claire. Il peut aussi devenir fragile lorsqu'un trop grand pouvoir repose sur un seul expert.
Le support n'est donc pas un accessoire du réseau. C'est le mécanisme humain qui corrige les enregistrements, autorise les exceptions, explique les décisions automatisées et coordonne les tiers. InterEdge expose suffisamment de canaux pour tester ce mécanisme avant de lui confier un chemin critique.
Les conditions limitent les promesses des pages produits
La page juridique d'InterEdge est l'une des parties les plus informatives de sa surface publique. Les conditions identifient InterEdge B.V. et Inter-IX, nomment les deux systèmes autonomes, utilisent l'adresse de Brielle et définissent les services comme incluant le transit, l'accès à l'échange, la location IPv4, la colocation et le conseil. Elles indiquent que le service sera fourni en utilisant des efforts commercialement raisonnables conformément à la description applicable et, là où convenu, un accord de niveau de service. Les délais de livraison sont indicatifs sauf s'ils sont expressément rendus stricts.
Ce libellé est important car la page "À propos" annonce une garantie de disponibilité de 99,99 % et la page de transit fait référence à un SLA de qualité opérateur. Un acheteur doit obtenir le calendrier de niveau de service réel. Il doit définir le composant mesuré, la méthode d'observation, les exclusions, le traitement de la maintenance, le processus de réclamation, les crédits, l'objectif de rétablissement et si une défaillance d'un amont, d'un centre de données, d'un cross-connect ou d'un registre est incluse. Un pourcentage accrocheur sans ces définitions ne peut pas évaluer le risque de temps d'arrêt.
Les conditions reconnaissent explicitement les dépendances tierces. InterEdge indique que lorsque le service dépend de transporteurs amont, d'opérateurs de centres de données, de fournisseurs de cross-connect ou de registres, ses obligations sont limitées à ce que ces parties mettent à disposition. Il se réserve des droits de maintenance planifiée et d'urgence. C'est une description réaliste de la fourniture réseau, mais elle déplace l'attention vers la gestion des fournisseurs. Le client doit savoir quelles dépendances se situent dans le niveau de service et lesquelles nécessitent une escalade séparée.
La tarification a des limites similaires. Les pages publiques de transit et de couche 2 montrent des tarifs mensuels bas et aucun frais d'installation, mais la page de transit exclut les frais de cross-connect et de transport. Les conditions légales stipulent que les prix excluent les taxes, l'équipement, les cross-connects, le transport, l'assurance, l'installation et les instructions sauf indication contraire. La location IPv4 et les noms de domaine sont facturés annuellement d'avance sauf accord différent, tandis que de nombreux services récurrents sont facturés mensuellement.
Une comparaison équitable doit inclure les frais d'installation, les ports, les optiques, les mains distantes, les coûts d'adresse, le dépassement, la taxe et le travail nécessaire à l'exploitation du service.
Les clauses de suspension sont significatives sur le plan opérationnel. InterEdge peut restreindre ou suspendre le service en cas de violation substantielle, d'utilisation nuisible ou de risques pour l'intégrité et la sécurité du réseau, et les violations graves de la politique d'échange peuvent entraîner la suspension ou la résiliation du port. La suspension ne supprime pas les obligations de paiement. C'est une raison supplémentaire de maintenir à jour la politique de routage et d'utilisation. Une erreur de configuration du client peut devenir à la fois un incident de service et une rupture contractuelle.
Les dispositions Inter-IX sont techniquement spécifiques. Elles interdisent les types de trames non supportés et le transit non autorisé, exigent que les routes soient enregistrées, autorisent le filtrage et l'échantillonnage de flux, et donnent à l'opérateur des pouvoirs d'application. Ces règles protègent la structure partagée, mais elles signifient également qu'un entité doit opérer avec compétence. Un client se connectant à l'échange doit traiter la politique de connexion comme faisant partie du runbook, avec des filtres explicites à son propre edge plutôt que de se fier entièrement à l'échange.
Les conditions appliquent le droit néerlandais et choisissent Amsterdam comme lieu de règlement des litiges, sous réserve des règles impératives. Elles font référence à la confidentialité et au RGPD. Elles autorisent également des mises à jour de la page juridique publiée. Le client doit conserver la version incorporée dans son accord et enregistrer tout écart négocié. Une page web qui change plus tard ne devrait pas redéfinir silencieusement un circuit critique.
Le contrat n'est ni hostile ni inhabituel. Sa valeur réside dans l'exposition de la frontière réelle sous le langage commercial. InterEdge s'engage sur un service défini selon des conditions écrites, tandis que la configuration du client, les tiers, l'utilisation licite, le paiement et les niveaux de service convenus séparément restent matériels. Un bon achat rend chacune de ces frontières visible avant l'installation.
L'économie est plus large que le prix du port
Les prix publics d'InterEdge rendent l'offre facile à comparer à première vue. Le transit commence avec un petit débit engagé et s'étend à travers des plans forfaitaires et au 95e percentile plus importants. Le transport couche 2 a également des paliers mensuels publiés. Inter-IX annonce des ports locaux gratuits et une option distante à faible coût. Le fournisseur indique qu'il n'exige pas de contrats annuels de transit et inclut un port d'échange avec les plans de transit. Ces choix peuvent abaisser le coût d'entrée pour un réseau qui souhaite tester un nouvel emplacement ou ajouter de la diversité.
La partie bon marché de la connectivité est souvent la ligne sur le site web. Le coût total comprend l'accès à cette ligne. Un cross-connect peut avoir des frais d'installation et des frais d'installation mensuels. Un client distant peut avoir besoin de transport jusqu'au point de présence. Un service redondant nécessite deux ports, des optiques, une capacité de routeur et une diversité physique. Les tables Internet complètes nécessitent de la mémoire et une marge de plan de contrôle.
La surveillance, la politique de routage, la revue de sécurité et le travail d'astreinte restent des coûts client même lorsque le fournisseur automatise le filtrage.
La facturation au 95e percentile nécessite également une compréhension opérationnelle. Elle peut être efficace pour le trafic en rafale car les échantillons les plus élevés sont exclus du calcul de facturation, mais un changement soutenu peut augmenter la facture. Les ports forfaitaires rendent le coût plus prévisible mais peuvent plafonner la capacité utilisable. InterEdge publie un tarif de dépassement sur sa page de transit, donc le client doit connaître l'intervalle d'échantillonnage, la direction, la méthode d'agrégation, la politique de dépassement et les seuils d'alerte.
Ces valeurs doivent alimenter l'automatisation de la capacité du client avant qu'une facture ne fournisse le premier avertissement.
L'offre d'échange gratuit a une logique économique différente. Le peering peut réduire l'utilisation du transit et améliorer les chemins vers les réseaux entités. Il crée également des ports routeur, des sessions, des filtres et des relations opérationnelles. La valeur dépend de la quantité de trafic pertinent qui peut réellement être échangée, pas de la capacité de port annoncée. Un client doit estimer le trafic par réseau de destination, identifier les pairs consentants, prendre en compte les politiques de route-server et bilatérales, et comparer le coût de transit économisé avec le transport et le travail d'ingénierie.
Les services IPv4 comportent un risque moins visible. Un bloc d'adresses peut avoir un prix de location attractif mais une mauvaise réputation, une géolocalisation incorrecte, une autorisation faible ou une sortie difficile. L'acheteur doit tester les principales bases de données de réputation, l'acceptation du courrier le cas échéant, les flux de géolocalisation, l'autorité d'origine de route et le DNS inverse avant l'acceptation. L'accord doit préciser qui supporte le coût si la ressource ne peut pas être utilisée aux fins prévues et comment le remplacement fonctionne.
Le conseil peut réduire le risque de migration tout en augmentant la dépendance. La comparaison pertinente n'est pas simplement le taux horaire. Elle inclut la découverte, la documentation, le contrôle d'accès, la revue par les pairs, les tests, la passation et la connaissance retenue du client. Une migration rapide qui ne laisse aucune construction reproductible ni chemin de rollback est coûteuse plus tard. Un engagement bien documenté peut être précieux même si les frais initiaux sont plus élevés.
La valeur commerciale doit être mesurée par rapport à la panne évitée. La diversité de transit est précieuse si elle supprime une dépendance réelle à un seul transporteur. La couche 2 est précieuse si l'application nécessite une connectivité inter-site prévisible. Le peering gratuit est précieux s'il atteint des partenaires de trafic importants. Les services d'adresses sont précieux s'ils maintiennent les enregistrements et la réputation utilisables. Le conseil est précieux s'il laisse le client avec un système plus sûr et exploitable.
Acheter le bundle parce que chaque composant est peu coûteux n'équivaut pas à prouver que le bundle résout ces problèmes.
Un enregistrement pratique d'acceptation et d'exploitation
La meilleure façon d'évaluer InterEdge est de construire un enregistrement de service avant que le trafic ne circule. Commencez par l'identité: InterEdge B.V., numéro d'immatriculation 87355299, l'entité contractante, l'accord applicable, la route de facturation, le propriétaire du service et l'avis de résiliation. Ajoutez le produit commandé, le point de présence, les délimitations A et Z, les identifiants de port et de cross-connect, la capacité, l'engagement, la méthode de facturation, les familles d'adresses et le niveau de support inclus.
La section de routage doit lister les deux ASN le cas échéant et garder leurs rôles séparés. Enregistrez l'ASN du client, InterEdge AS213753 pour le transit, AS56584 pour le contexte Inter-IX, les adresses de session, l'authentification, les limites de maximum de préfixes, les longueurs de préfixe acceptées, le choix de route par défaut ou table complète, la source IRR, la politique RPKI, les paramètres BFD et chaque communauté approuvée. La valeur de blackhole doit être confirmée directement car les enregistrements publics actuels ne concordent pas.
Stockez les autorisations d'origine de route et les objets route avec les propriétaires et les dates de révision.
La section physique doit nommer les installations, les racks, les meet-me rooms, les fournisseurs de cross-connect, les fibres, les optiques, les ports routeur, les alimentations et les affirmations de diversité. "Ports différents" ne suffit pas si les deux fibres partagent un panneau ou un conduit. Pour la couche 2, ajoutez les valeurs VLAN et QinQ, la MTU, les identifiants de service EVPN ou VXLAN là où le fournisseur les expose, la conception de chemin protégé et la responsabilité de prévention des boucles. Pour un échange distant, documentez le tunnel underlay et qui possède chaque extrémité.
L'acceptation doit mesurer à la fois le fonctionnement normal et la panne contrôlée. Établissez une référence pour la latence, la gigue, la perte et le débit vers les destinations pertinentes. Confirmez l'accessibilité IPv4 et IPv6. Comparez le nombre de routes et les chemins sélectionnés. Retirez et restaurez un préfixe de test. Exercez les communautés approuvées. Testez un port ou un chemin à la fois là où la redondance existe. Vérifiez que les alarmes arrivent, que les tickets sont ouverts, que l'accusé de réception du NOC est enregistré et que la propre surveillance du client distingue les pannes de transit, d'échange et de transport.
La section sécurité doit couvrir la prévention des fuites de préfixes et de routes, RPKI, les contrôles de maximum de préfixes, le blackholing, l'accès au port, l'authentification de gestion, l'accès privilégié au conseil et la réponse aux abus. Un test de blackhole doit utiliser un préfixe isolé et une fenêtre écrite. Un test d'échange doit confirmer les règles de one-MAC et de trafic autorisé sans perturber les autres membres. Le client doit conserver la preuve que les filtres se comportent comme convenu après une modification de configuration.
La section données doit classer les données de facturation, les enregistrements de support, les flux échantillonnés, la télémétrie de routage, les données d'enregistrement d'adresses et l'accès des consultants. Enregistrez la conservation, l'emplacement, les tiers et les obligations de suppression là où ils importent. L'adresse de l'entreprise néerlandaise et la déclaration RGPD appartiennent à cet enregistrement, mais elles ne doivent pas remplacer les réponses spécifiques au produit.
La section support doit inclure les routes d'escalade NOC, ventes, abus et gestion; les définitions de gravité; les objectifs d'accusé de réception et de mise à jour; les canaux de maintenance; les contacts clients autorisés; et les règles de changement d'urgence. Testez le chemin téléphonique et de ticket lors de l'intégration. Une réponse polie à un test planifié fournit plus de preuves qu'une déclaration non testée de disponibilité 24/7.
Enfin, rédigez la sortie avant l'activation. Indiquez comment les sessions BGP sont supprimées, comment les objets route et les autorisations sont transférés ou supprimés, comment les adresses louées sont restituées, comment le DNS inverse et la géolocalisation sont modifiés, comment les ports d'échange sont déconnectés, comment les configurations et la télémétrie sont exportées, et quand la facturation s'arrête. Pour le conseil, exigez la suppression des identifiants et la remise de la documentation. Pour la couche 2, planifiez le circuit parallèle ou la migration routée nécessaire pour éviter une coupure brutale.
Cet enregistrement n'est pas une paperasse pour elle-même. C'est la surface de contrôle du client. Il rend le réseau attribuable, interrogeable et récupérable lorsque le personnel, les routes, les installations ou les fournisseurs changent.
Bottom line
InterEdge B.V. a plus de substance vérifiable que son profil public compact ne le suggère. L'identité légale néerlandaise est liée de manière cohérente au numéro d'immatriculation 87355299, à une adresse à Brielle et à deux enregistrements RIPE. AS213753 a des preuves actuelles de routes, d'échanges et d'installations, tandis qu'AS56584 est clairement associé à Inter-IX. L'entreprise publie une gamme de produits réelle, des contrôles BGP explicites, un looking glass, des routes NOC et abus, une présence en installation, des prix de services et des conditions d'échange détaillées.
Ces enregistrements rendent une conversation technique sérieuse possible.
Les limites sont tout aussi importantes. La plupart des déclarations de performance et d'échelle proviennent des propres pages d'InterEdge ou de répertoires réseau auto-maintenus. Les preuves publiques ne montrent pas un historique de disponibilité audité, une distribution des temps de réponse du support, des cas de rétablissement client, un modèle de dotation complet, une localité route par route complète ou un compte indépendant de la qualité de service.
Les comptages de pairs et d'installations utilisent des définitions différentes, la liste d'amont annoncée est plus large que la simple politique RIPE, et la documentation publique de la communauté de blackhole contient une valeur ASN contradictoire.
Aucune de ces lacunes ne rend le service inadapté. Elles définissent le travail qu'un acheteur doit faire. Confirmez l'entité contractante et le produit. Obtenez le calendrier de niveau de service réel. Demandez une conception de chemin et de dépendance spécifique à l'emplacement. Vérifiez la politique de routage, RPKI, les filtres de préfixes et les communautés dans un test contrôlé. Tarifiez le cross-connect, le transport et le travail d'exploitation en plus du port. Séparez la surveillance du transit, de l'échange et de la couche 2. Contractez pour le support et la localité plutôt que de les inférer.
Concevez la sortie avant que la première route ne soit acceptée.
La proposition la plus forte d'InterEdge n'est pas qu'un nom néerlandais garantit l'edge. C'est que l'entreprise expose suffisamment d'identité, de détails réseau et de politique pour qu'un client puisse construire une frontière de service fondée sur des preuves. Que cette frontière soit fiable sera décidé par la conception signée, les personnes qui répondent et les enregistrements qui restent corrects lorsque le réseau change.

