Summary
- InterEdge B.V. has an attributable Dutch identity, two clearly named autonomous systems, public transit and interconnection products, current RIPE and PeeringDB records, a looking glass, published routing controls, named NOC and abuse routes, and Dutch-law service terms.
- That record makes the company assessable, but it does not independently prove the advertised uptime, peer totals, route quality, staffing depth, response times, complete traffic locality or recovery performance. Buyers still need a signed service boundary, an acceptance test and an exit design.
The edge is a chain of records
A network service becomes valuable at the moment nobody wants to think about it: when a remote site opens, a content platform bursts, a cloud route changes, or a primary carrier drops a session. At that point the customer does not need a broad promise about global connectivity. It needs to know which company accepted the order, which autonomous system is carrying the traffic, which physical handoff belongs to the circuit, which routes should be present, which filters are active, who is watching the port, and who can reverse a bad change.
InterEdge B.V. has enough of that public record to deserve a close assessment. Its contact page names a Dutch private company at Krammer 8 in Brielle, South Holland, gives registration number 87355299 and a Dutch VAT number, and associates the business with AS213753 and AS56584. The RIPE database independently connects the same company name, registration number and Brielle address to both autonomous systems. PeeringDB exposes public network operations, sales and abuse contacts and lists current exchange and facility records for AS213753. A public looking glass identifies an Amsterdam location.
The company also publishes service descriptions, routing-community guidance and terms governed by Dutch law.
Those are meaningful signals because they make the offer attributable. They do not turn every statement on the website into an observed result. A registration number establishes a legal identity, not service quality. An autonomous-system record establishes the holder of a routing identifier, not the latency of a customer's path. A PeeringDB entry records declared interconnection data, not continuous availability. A published NOC address creates a channel, not an acknowledgement target. A price page establishes an offer at a point in time, not the full installed cost.
This distinction is particularly important for InterEdge because the visible offer spans several different businesses. IP transit carries a customer's internet routes. Layer 2 transport extends an Ethernet domain between handoffs. Inter-IX provides a shared peering fabric with its own connection rules. IP services cover leasing, transfer, reverse DNS, geolocation and abuse handling. Consultancy reaches into cloud migrations, Kubernetes, network architecture, hands-on data-centre work and temporary staffing. The same supplier name sits above products with very different failure modes and responsibility boundaries.
The useful question is therefore not whether InterEdge is a real Dutch network operator. The public record supports that conclusion. The useful question is whether a particular InterEdge service can be specified, tested, monitored and replaced with tolerable risk. That requires a buyer to separate identity from performance, topology from marketing, automation from accountability, and a Dutch address from an actual data-locality commitment.
The company identity is stronger than the origin story
InterEdge's corporate record is unusually concrete for a young-looking network brand. The company contact page gives a street address, telephone number, company registration, VAT identifier, bank details, email route and both autonomous systems. RIPE's organisation entity for InterEdge B.V. repeats registration number 87355299, the Krammer 8 address, the Netherlands country code and an abuse contact. The role record carries the same public telephone number shown by PeeringDB. These matching identifiers reduce the risk that a buyer is dealing with a floating brand that cannot be tied to a contracting entity.
The dates in the network registries also help bound the history. RIPE created the organisation entity in August 2022. AS56584, named INTER-IX, was assigned in October 2022. AS213753, named interedge, was assigned in December 2024. These are dates for registry entities and number assignments, not proof that every service began on those days. The website footer says 2008-2026, but a copyright range is not an incorporation record and should not be used as one. Procurement should use the Dutch company registration, signed agreement and current registry records as the identity anchors.
The site also lists InterEdge L.L.C. at a Delaware address, using the same website, telephone structure, bank details and autonomous systems. That can be useful for customers seeking a US commercial route, but it creates a contract question rather than resolving one. The buyer should record which entity is quoting, invoicing and carrying liability; which entity is the data processor where consultancy or account data is involved; and which law and venue apply. The public terms are written for InterEdge B.V. and point to Dutch law and the competent court in Amsterdam.
A customer contracting with another entity should not assume those provisions transfer unchanged.
There is a further reason to keep the legal and network identities aligned. Address space, BGP sessions, cross-connects and internet-exchange memberships often involve different records. A quote may use a sales brand, a letter of authorisation may identify an address holder, a route object may identify a maintainer, and the physical cross-connect may be ordered through a data-centre account. If those names diverge, a routine change can stall while each provider waits for another party's authority.
The service record should therefore contain the contracting entity, ASN, IRR or RPKI authority, facility account, port identifier, billing contact, NOC contact and abuse route.
InterEdge's matching public records lower that administrative risk, but they do not eliminate it. The site offers IPv4 leasing and inter-registry transfers as well as transit. In that business, the party holding a resource, the party announcing it, the party leasing it and the party paying for it may not be the same. A customer should insist that the commercial documents state who may originate each prefix, who creates route authorisations, who updates reverse DNS and geolocation, who receives abuse notices, and what happens to those records when the agreement ends.
Identity is thus the strongest part of the public case. InterEdge B.V. can be named, located and connected to live network records. The remaining work is to ensure that the same precision reaches the purchased service.
One supplier name, five operating surfaces
The phrase "edge services" can hide more than it reveals. InterEdge's own pages are clearer when read product by product. The principal commercial service is IP transit. The company advertises IPv4 and IPv6 BGP handoffs, dedicated VLANs, automatic prefix filtering, default-route or full-table options, flat or 95th-percentile billing and monthly terms across a range of committed capacities. The page says cross-connect and transport charges are excluded and publishes an overuse rate.
That last detail matters: the attractive port price is not the same as the total monthly cost of delivering traffic to a customer's rack, office or cloud on-ramp.
Layer 2 transport is a separate product. InterEdge describes point-to-point Ethernet across its European points of presence, with a dedicated VLAN per circuit, jumbo frames, an EVPN control plane with a VXLAN data plane, and QinQ for preserving customer VLAN tags. The page frames the service around Amsterdam and Paris and names applications such as data-centre interconnect, cloud connectivity, storage replication and low-latency platforms.
These claims define a plausible technical product, but the customer still needs the exact A and Z locations, protected or unprotected path, maximum transmission unit, bandwidth profile, diversity standard and fault-demarcation points in the order.
Inter-IX is different again. The exchange page advertises free ports at several capacities and a paid remote option over GRE. The legal page is more useful than the promotional language because it explains what the free fabric is for. Entities must use an assigned public ASN and BGP, keep to assigned peering addresses, use one source MAC per port, suppress prohibited link-local traffic, register advertised routes and avoid using the exchange as unauthorised transit or backhaul. Free access is not unbounded transport. It is a shared peering service with specific technical and commercial limits.
The IP-services offer reaches beyond carriage. InterEdge describes IPv4 leasing, IPv4 and IPv6 address management, reverse-DNS work, geolocation updates, proactive monitoring, abuse handling, transfers between regional internet registries and escrow-assisted transactions. This is record-intensive work. A prefix can be routable and still be commercially troublesome if its registration is stale, its geolocation is wrong, its reverse-DNS authority is unclear, its reputation is poor or an abuse mailbox is unattended. For an address customer, the operating value lies as much in the quality of those records as in the address block itself.
Consultancy creates the widest responsibility surface. The company advertises cloud migrations, landing zones, Kubernetes and Docker work, hands-on data-centre services, network architecture, interim staffing and DevOps staffing. In those engagements, InterEdge may be designing or changing a customer's own systems rather than carrying packets through an InterEdge service. The customer must define access rights, change approval, code ownership, credential handling, documentation, acceptance, rollback and the end of privileged access.
A good transit supplier does not automatically become a good migration partner, and a skilled consultant does not automatically create a managed service.
These products can reinforce each other. A customer might use InterEdge transit at a Dutch facility, an Inter-IX port for local peering, a Layer 2 circuit to another site, leased addresses for a temporary deployment and consulting help to configure BGP. That bundle may reduce the number of suppliers. It may also concentrate support, billing and change authority in one organisation. The commercial assessment should model both outcomes.
The first purchasing discipline is therefore to name the service precisely. "InterEdge connectivity" is not a testable entity. "A dual-stack BGP transit port with a stated commit at a named facility, an agreed routing policy, a defined service level and a documented cancellation process" is testable. So is "a protected Layer 2 circuit between two named demarcation points with a stated MTU and restoration target." The more exact the product boundary, the easier it becomes to judge the public evidence without granting it powers it does not have.
Two autonomous systems should not be treated as one
The two ASNs on InterEdge's contact page represent different operating roles. AS213753 is the current InterEdge network-services ASN. Its RIPE entity names InterEdge B.V., lists import and export policies for Hurricane Electric, GTT and Cogent, and links to the AS213753:AS-INTEREDGE set. PeeringDB classifies it as enterprise and network services, records IPv4 and IPv6 support, and exposes its exchange and facility presence. The transit, Layer 2 and network pages consistently centre this ASN.
AS56584 is named INTER-IX. RIPE also ties it to InterEdge B.V., but the number belongs to the exchange context. InterEdge's legal terms explicitly call Inter-IX AS56584 and separate exchange participation from InterEdge transit. This matters operationally. A route seen on an InterEdge transit path, a route-server session on an exchange, and a member's bilateral peering session are not interchangeable evidence. Each has a different policy owner and fault domain.
The distinction is easy to lose because both identifiers appear on the same contact page and the supplier operates the exchange. A buyer should preserve it in diagrams and incident records. The transit edge should show AS213753, the customer's ASN, upstream or peer paths and the commercial transit handoff. The exchange edge should show the Inter-IX fabric, route servers if used, the customer's exchange address and any bilateral sessions. A Layer 2 circuit should be shown as transport, not as an autonomous system relationship.
Keeping these roles separate improves incident diagnosis. If a customer's BGP session to AS213753 drops, the failure might be the cross-connect, customer router, transit port or InterEdge edge. If a route-server session on Inter-IX drops while the transit session remains healthy, the fault is narrower. If both fail at one facility, the shared physical handoff or site may be the common cause. If a remote exchange over GRE fails, the underlay may be healthy while the tunnel or exchange session is not. A single dashboard labelled "InterEdge" can blur all of those states.
It also improves contract interpretation. The Inter-IX terms prohibit unauthorised transit over the shared fabric and allow monitoring and enforcement. That is a policy for protecting exchange entities. It should not be confused with the customer's purchased transit policy. Conversely, a free exchange port does not replace a transit contract merely because both reach other networks. Settlement-free peering reaches willing peers and advertised routes; transit is bought to reach the wider internet under a different commercial obligation.
The public record is strong enough to show that InterEdge understands this separation. The buyer's task is to retain it through ordering, automation and recovery. Every session should have an owner, purpose, remote ASN, address family, maximum-prefix setting, authentication policy, routing-policy reference and escalation path. The supplier name can be shared. The controls cannot.
Network records reveal reach, not experience
AS213753 has a visible and recently updated public footprint. PeeringDB's June 2026 record lists four exchange connections: INTERIX, Frys-IX, Speed-IX and nine. The declared capacities range from a smaller Speed-IX port to larger Frys-IX, nine and INTERIX connections. It also lists nineteen facilities, mostly in the Netherlands, with additional records in Paris and the Frankfurt area. The Dutch entries include Nikhef, several Equinix Amsterdam sites, Bytesnet Rotterdam, ColoCenter Zoetermeer, a Hague facility, Greenhouse locations and Qupra sites.
The company's network page broadly agrees on the shape of the footprint. It names Dutch sites, Paris and other locations, says the network uses Juniper routers and Arista switches, and identifies several exchange and upstream relationships. Its live counters say six transit carriers, more than 1,791 private peerings and more than fifteen connected data centres. The about page, however, says more than 1,400 direct peerings. PeeringDB gives a different type of count: four public exchange connections and nineteen facility records. BGP.tools exposes a large AS-set and a set of observed exchange connections.
These figures should not be forced into one number. "Private peerings," "direct peers," AS-set members, route-server entities, facility presence and exchange ports measure different things. They may also update at different times. A buyer should ask for the definition and observation date behind any count used in a proposal. For resilience, the more important evidence is the exact path and policy available to that customer, not the network's headline peer total.
RIPE's current AS213753 record names three upstream policies: AS6939, AS3257 and AS174. The website's network page additionally names RETN and Arelion among its upstream providers. That difference is not proof that either record is wrong. Some relationships may not be expressed in a simple public import statement, and web pages can describe a broader blend than a given observation sees. It is, however, a reason not to reproduce a supplier list as if every carrier were active at every point of presence.
The buyer should request a location-specific design. Which upstreams are active at the ordered site? Which are physically diverse? Does the customer's port reach one router or two? Are redundant ports on different line cards, chassis, power feeds and fibre paths? Is the Layer 2 path protected, and what event triggers switching? Does a full-table customer receive the same policy on both sessions? Are routes learned from exchanges preferred over transit? Which communities let the customer influence propagation, and which controls are provider-only?
Public route observations offer another bounded signal. A July 2026 RIPEstat observation showed AS213753 announcing two IPv4 prefixes and one IPv6 prefix with normal visibility during the observed interval. One of the IPv4 announcements had a valid RPKI authorisation for AS213753. This supports the existence of an active routing system and at least one correctly authorised origin. It does not establish that all customer prefixes are authorised, that every route is accepted correctly, or that invalid announcements would always be rejected on every path.
The looking glass adds practical value because it gives customers a view from Amsterdam. A useful pre-contract test can compare what the looking glass sees with what the customer's router receives. But a looking glass is an observation point, not an availability guarantee. It may sit behind a web front end, expose only selected routers and omit policy detail. It should complement route collectors, customer telemetry and supplier tickets, not replace them.
The public network record therefore answers one question well: InterEdge B.V. operates a visible routing and interconnection surface with current records in the Dutch and nearby European ecosystem. It answers a more demanding question only partially: how a particular customer's traffic will behave under failure. That second answer has to come from the design, contract and acceptance test.
Routing automation is useful only when the documentation agrees
InterEdge's operating model depends heavily on automation. The transit page advertises automatic prefix filtering. The network and transit pages describe RPKI validation. The BGP-community page gives customers tags for controlling upstream advertisement and blackholing. The legal terms for Inter-IX describe route registration, IRR and RPKI filters, route-server controls, one-MAC rules, allowed frame types, link-local suppression and flow sampling. These are the mechanisms that let a network deliver repeated decisions without asking an engineer to review every route or frame by hand.
The benefit is real. Prefix filters can prevent an accidental broad announcement. RPKI origin validation can distinguish an authorised origin from an invalid one. Maximum-prefix controls can stop a session from flooding a router. BGP communities can let a customer suppress or prepend announcements towards selected upstreams. Remotely triggered blackholing can discard attack traffic before it consumes a constrained link. Exchange-port controls can contain mistakes that would otherwise affect a shared fabric.
Each mechanism also creates a failure path. A stale IRR object can cause a legitimate route to be filtered. An expired or incorrect route-origin authorisation can turn a valid business change into an invalid route. A maximum-prefix value can be set below a customer's normal growth. A broad blackhole can remove good traffic with the bad. A community can be mistyped, interpreted differently at another provider or stripped across a boundary. Automation reduces routine labour by making decisions consistently, but consistency is dangerous when the input record is wrong.
InterEdge's public BGP documentation contains a small but important example. The BGP-community page lists the blackhole value with 213357 as its first number, while the same page's upstream-control communities use 213753, and the current RIPE aut-num record lists the blackhole community as 213753:0:666. One transposed digit is enough to make an emergency control ineffective or to produce an unintended result if another network recognises the value.
The proper response is not to guess which page the routers follow. A customer planning to use blackholing should obtain the current technical specification from the NOC, validate it in a controlled test prefix and retain the confirmed value with an effective date. The same check should cover standard and large community formats, route-server behaviour, accepted prefix lengths, RPKI policy, IRR source, maximum-prefix limits, default-route handling and what happens when validation data cannot be fetched.
This documentation mismatch is also a useful test of support accountability. A precise question should produce a precise answer: which community is implemented on the relevant edge, how is it propagated, what discard action occurs, can it be applied per prefix and address family, and how is recovery verified? The answer should be written into the service record rather than left in an email chain that disappears when staff change.
Routing automation should then be tested like software. Announce an authorised test prefix and confirm acceptance. Withdraw it and measure convergence. Create an intentionally invalid origin in a lab or agreed maintenance window and confirm the expected policy without endangering live traffic. Exercise each approved upstream-control community. Test maximum-prefix warning and shutdown behaviour. Verify IPv4 and IPv6 separately. Confirm whether BFD is available and what timers are supported. Compare the customer's received routes with the looking glass and an independent route collector.
The objective is not to challenge the supplier with exotic cases. It is to replace assumptions with observations before a real incident. InterEdge publishes enough technical surface to make such testing possible. The customer should use it.
Layer 2 changes the fault domain
InterEdge's Layer 2 offer deserves separate scrutiny because Ethernet simplicity can be deceptive. A dedicated VLAN between Amsterdam and Paris may look to a customer like a long cable. Underneath, the provider describes an EVPN and VXLAN overlay, with scalable MAC and IP learning and multi-tenant separation. It also supports jumbo frames and QinQ. Those are standard tools for building flexible carrier Ethernet, but each introduces state that the customer and supplier must understand.
An EVPN control plane distributes reachability information. VXLAN carries frames across a routed underlay. QinQ nests customer tags inside a service tag. Jumbo frames raise the payload that can cross the path. A failure can therefore occur in the physical circuit, underlay routing, tunnel endpoint, EVPN state, VLAN mapping, tag handling, maximum transmission unit or customer device. A simple link-up light does not prove that the complete service is healthy.
The acceptance plan should start at the demarcation. Record the supplier port, customer port, optics, speed and duplex, VLAN tags, expected MAC behaviour and maximum transmission unit. Test ordinary and maximum-size frames with the correct overhead. Verify that customer tags survive where QinQ is ordered. Confirm that unexpected VLANs are blocked. Measure unicast loss, latency and jitter in both directions. Test MAC moves and failover without creating a loop. If diverse routing is purchased, verify that the two paths do not share an unrecorded physical segment.
Storage replication and virtual-machine movement deserve particular caution. The service page names these as applications that benefit from larger frames. That does not mean every storage workload can tolerate the available latency, loss profile or failure mode. Synchronous replication has a stricter round-trip budget than asynchronous transfer. A split Layer 2 domain can also stretch broadcast, failure and security boundaries between sites. The customer should decide whether extending the same network is genuinely required or whether a routed design would contain faults better.
The commercial order should say whether the circuit is protected or unprotected, how capacity is committed and capped, whether burst is allowed, how overuse is measured, which maintenance notifications apply and which service level covers the path. The public page mentions carrier-grade monitoring and protected paths in its positioning, but a customer should not assume either feature is included in every listed plan. The signed order and technical design must settle that.
Layer 2 can be a strong complement to InterEdge's transit and facility presence. It can also create a shared dependency. If both transit ports and the inter-site circuit ride the same provider backbone, one control-plane or fibre event could affect the whole design. Resilience may require a second provider, a different physical path or an independent internet route at one site. Supplier consolidation is operationally convenient only while the remaining failure domain is acceptable.
Local company, regional network, uncertain packet locality
InterEdge is plainly anchored in the Netherlands. Its company address is in Brielle. Its current PeeringDB facility list is dominated by Amsterdam, Rotterdam, Zoetermeer, The Hague and Naaldwijk. Its public looking glass shows Amsterdam. The legal terms apply Dutch law and refer to GDPR. For a Dutch buyer, that creates useful proximity for contracting, billing and some on-site work.
It does not establish that all customer traffic, telemetry or support data remains in the Netherlands. PeeringDB also lists InterEdge at a Paris facility and a facility in the Frankfurt area. The Layer 2 page describes an Amsterdam-to-Paris service. IP transit is designed to exchange traffic with external networks, so the route to a destination may leave the country by definition. Even when both endpoints are Dutch, BGP policy and congestion can change the path unless the service is explicitly engineered to keep it local.
The public website illustrates another layer of dependency. In a July 2026 DNS observation, interedge.com used Cloudflare addresses and nameservers, while its mail exchange records pointed to Google's mail service. That says something about the company's public web and email front door, not the path of a customer's transit traffic. It does, however, show why "Dutch provider" is not a complete locality statement. Customer communications, portal data and support email may touch third-party platforms under separate terms.
Different InterEdge products create different data questions. IP transit carries packet headers and payloads but normally does not store the customer's application state as a hosting service would. Inter-IX terms say the operator may monitor control traffic, sampled flows, protocol data and header information for operations, security and compliance. Address services may store registrant, authorisation, reputation and abuse records. Consultancy may expose engineers to cloud consoles, configuration repositories, credentials, logs and application data.
A hands-on data-centre engagement may involve physical access records and asset inventories.
A serious locality review should therefore classify data rather than ask for one country answer. Where are account and billing records held? Where are support tickets and email processed? What routing and flow telemetry is retained, for how long and for what purpose? Which third parties receive it? Where do consultants connect from, and how is privileged access recorded? Which facilities carry the ordered circuit? Can maintenance or failover move traffic to another country? Does the customer need data residency, routing locality, support locality or all three?
The public terms say personal data is processed in accordance with GDPR and a privacy statement at the legal address. That is a governance commitment, but it is not a customer-specific data-processing agreement, retention schedule or transfer map. A regulated customer should obtain those documents and identify the controller and processor roles for each service. It should also ask whether the supplier can meet deletion, access and audit obligations without disrupting operational security records.
Local support labour has a similar nuance. The consultancy page offers data-centre hands-on work and interim or DevOps staffing. That is stronger evidence of a human service surface than a generic contact form. Yet the public pages do not state how many engineers are available in each country, which languages are covered on each shift, or whether a named site can receive a technician within a fixed time. The buyer should contract for the locality that matters instead of inferring it from the headquarters.
InterEdge's Dutch identity is commercially useful. Its network is regional and interconnected by design. Those facts should be recorded separately so that neither is mistaken for a guarantee about every packet, log or engineer.
Support is the control plane people notice during failure
InterEdge publishes more support structure than many small network suppliers. PeeringDB lists distinct NOC, sales and abuse email routes, all tied to the Dutch telephone number. The contact page invites port deployment, support and billing enquiries. The about page says expert support is available around the clock and describes in-house engineers. The consultancy page offers hands-on, architecture and staffing work. The public professional profile of founder and director Desmond van der Winden describes long experience across Linux, Windows, hosting, fibre, BGP, OpenStack, cloud and data-centre operations.
Together, these records make a credible case that technical work is part of the business, not merely outsourced behind a storefront. They still leave the operational questions that matter most to a buyer. How is the NOC staffed outside Dutch business hours? Is the telephone answered by an engineer, an answering service or an escalation desk? What is the acknowledgement target for a total outage? Is abuse handled by the same on-call team? How many simultaneous incidents can the team support? Which changes need senior approval? Which site visits are included and which are separately billed?
The website's around-the-clock statement should therefore be converted into a support matrix. Severity should be based on customer impact. Each severity needs an allowed channel, acknowledgement target, update interval, restoration objective and escalation ladder. The customer should know whether a ticket, email or phone call starts the clock and what evidence the NOC needs. For routing incidents, that usually includes the local and remote ASN, session address, affected prefixes, start time, recent changes, route samples and traceroutes from both directions.
Support quality also depends on authority. A first-line engineer may see that a BGP session is down but lack access to change a filter. A consultant may understand the customer's Kubernetes cluster but lack authority over the carrier edge. A data-centre technician may replace an optic but not approve a cross-connect change. The escalation plan should identify who can act at each layer and how the customer authorises an emergency change.
Abuse handling is especially important for leased address space. A delayed or opaque response can damage the reputation of a prefix and create blocking far beyond one incident. The customer should know where complaints arrive, how evidence is shared, what response time applies, when a prefix can be suspended, how false reports are challenged and how reputation recovery is documented. InterEdge advertises white-glove abuse handling, but the measurable service belongs in the order.
Consultancy increases the need for role clarity. A temporary engineer can accelerate migration and reduce a skills gap. The same engineer can also become the only person who understands a design. Every engagement should produce customer-owned diagrams, configuration records, decision logs, rollback steps and credential transfer. Access should be time-bound and individually attributable. The final acceptance should verify that the customer's own team can operate the result after the consultant leaves.
The public professional profile is useful context, but it is self-published and centred on one person. It does not establish the depth of the current team. A buyer should ask which named service owner and backup engineer will support the account, then test the escalation path during onboarding. A modest provider can outperform a large carrier when ownership is clear. It can also become fragile when too much authority rests with one expert.
Support is therefore not an accessory to the network. It is the human mechanism that corrects records, authorises exceptions, explains automated decisions and coordinates third parties. InterEdge exposes enough channels to test that mechanism before entrusting it with a critical path.
The terms narrow the promises on the product pages
InterEdge's legal page is one of the most informative parts of its public surface. The terms identify InterEdge B.V. and Inter-IX, name the two autonomous systems, use the Brielle address and define services to include transit, exchange access, IPv4 leasing, colocation and consultancy. They say service will be provided using commercially reasonable efforts according to the applicable description and, where agreed, a service-level agreement. Delivery times are indicative unless expressly made strict.
That wording matters because the about page advertises a 99.99 percent uptime guarantee and the transit page refers to a carrier-grade SLA. A buyer should obtain the actual service-level schedule. It should define the measured component, observation method, exclusions, maintenance treatment, claim process, credits, restoration target and whether a failure of an upstream, data centre, cross-connect or registry is included. A headline percentage without those definitions cannot price downtime risk.
The terms explicitly recognise third-party dependencies. InterEdge says that where service depends on upstream carriers, data-centre operators, cross-connect providers or registries, its obligations are limited to what those parties make available. It reserves planned and emergency maintenance rights. This is a realistic description of network delivery, but it shifts attention to supplier management. The customer needs to know which dependencies sit inside the service level and which require separate escalation.
Pricing has similar boundaries. Public transit and Layer 2 pages show low monthly rates and no setup fees, but the transit page excludes cross-connect and transport charges. The legal terms state that prices exclude taxes, equipment, cross-connects, transport, insurance, installation and instruction unless stated otherwise. IPv4 leasing and domain names are invoiced annually in advance unless agreed differently, while many recurring services are invoiced monthly. A fair comparison must include facility charges, ports, optics, remote hands, address costs, overage, tax and the labour required to operate the service.
The suspension clauses are operationally significant. InterEdge may restrict or suspend service for material breach, harmful use or risks to network integrity and security, and serious exchange-policy breaches can result in port suspension or termination. Suspension does not remove payment obligations. This is another reason to keep route and usage policy current. A customer's configuration error can become both a service incident and a contractual breach.
The Inter-IX provisions are technically specific. They prohibit unsupported frame types and unauthorised transit, require routes to be registered, allow filtering and flow sampling, and give the operator enforcement powers. Those rules protect the shared fabric, but they also mean a entity must operate competently. A customer connecting to the exchange should treat the connection policy as part of the runbook, with explicit filters at its own edge rather than relying entirely on the exchange.
The terms apply Dutch law and choose Amsterdam as the dispute venue subject to mandatory rules. They refer to confidentiality and GDPR. They also allow updates to the published legal page. The customer should preserve the version incorporated into its agreement and record any negotiated departures. A web page that changes later should not silently redefine a critical circuit.
The contract is not hostile or unusual. Its value lies in exposing the real boundary beneath the sales language. InterEdge commits to a defined service under written terms, while customer configuration, third parties, lawful use, payment and separately agreed service levels remain material. A good purchase makes each of those boundaries visible before installation.
The economics are broader than the port price
InterEdge's public prices make the offer easy to compare at first glance. Transit starts with a small committed rate and scales through larger flat and 95th-percentile plans. Layer 2 transport also has published monthly tiers. Inter-IX advertises free local ports and a low-cost remote option. The supplier says it does not require annual transit contracts and includes an exchange port with transit plans. These choices can lower entry cost for a network that wants to test a new location or add diversity.
The cheap part of connectivity is often the line item on the website. The full cost includes getting to the line item. A cross-connect may have a setup charge and monthly facility fee. A remote customer may need transport to the point of presence. Redundant service needs two ports, optics, router capacity and physical diversity. Full internet tables require memory and control-plane headroom. Monitoring, route policy, security review and on-call labour remain customer costs even when the provider automates filtering.
95th-percentile billing also requires operational understanding. It can be efficient for bursty traffic because the highest samples are discarded from the billing calculation, but a sustained shift can increase the bill. Flat-rate ports make cost more predictable but may cap usable capacity. InterEdge publishes an overuse rate on its transit page, so the customer should know the sample interval, direction, aggregation method, burst policy and alert thresholds. Those values should feed the customer's capacity automation before an invoice supplies the first warning.
The free exchange offer has a different economic logic. Peering can reduce transit use and improve paths to participating networks. It also creates router ports, sessions, filters and operational relationships. The value depends on how much relevant traffic can actually be exchanged, not the headline port capacity. A customer should estimate traffic by destination network, identify willing peers, account for route-server and bilateral policies, and compare the saved transit cost with transport and engineering work.
IPv4 services carry less visible risk. An address block may have an attractive lease price but poor reputation, incorrect geolocation, weak authorisation or a difficult exit. The buyer should test major reputation databases, mail acceptance where relevant, geolocation feeds, route-origin authority and reverse DNS before acceptance. The agreement should say who bears the cost if the resource cannot be used for the intended purpose and how replacement works.
Consultancy can lower migration risk while increasing dependence. The relevant comparison is not simply the hourly rate. It includes discovery, documentation, access control, peer review, testing, handover and the customer's retained knowledge. A fast migration that leaves no reproducible build or rollback path is expensive later. A well-documented engagement can be valuable even if the initial fee is higher.
Commercial value should be measured against the failure being avoided. Transit diversity is valuable if it removes a real single-carrier dependency. Layer 2 is valuable if the application requires predictable inter-site connectivity. Free peering is valuable if it reaches material traffic partners. Address services are valuable if they keep records and reputation usable. Consultancy is valuable if it leaves the customer with a safer, operable system. Buying the bundle because each component is inexpensive is not the same as proving the bundle solves those problems.
A practical acceptance and operating record
The strongest way to assess InterEdge is to build one service record before traffic moves. Start with identity: InterEdge B.V., registration number 87355299, the contracting entity, governing agreement, invoice route, service owner and cancellation notice. Add the ordered product, point of presence, A and Z demarcations, port and cross-connect identifiers, capacity, commit, billing method, address families and included support level.
The routing section should list both ASNs where relevant and keep their roles separate. Record the customer's ASN, InterEdge AS213753 for transit, AS56584 for Inter-IX context, session addresses, authentication, maximum-prefix limits, accepted prefix lengths, default or full-table choice, IRR source, RPKI policy, BFD settings and every approved community. The blackhole value should be confirmed directly because the current public records do not agree. Store route-origin authorisations and route objects with owners and review dates.
The physical section should name facilities, racks, meet-me rooms, cross-connect providers, fibres, optics, router ports, power feeds and diversity claims. "Different ports" is not enough if both fibres share a panel or conduit. For Layer 2, add VLAN and QinQ values, MTU, EVPN or VXLAN service identifiers where the supplier exposes them, protected-path design and loop-prevention responsibility. For a remote exchange, document the tunnel underlay and who owns each end.
Acceptance should measure both normal operation and controlled failure. Establish a baseline for latency, jitter, loss and throughput to relevant destinations. Confirm IPv4 and IPv6 reachability. Compare route counts and selected paths. Withdraw and restore a test prefix. Exercise approved communities. Test one port or path at a time where redundancy exists. Verify that alarms arrive, tickets are opened, NOC acknowledgement is recorded and the customer's own monitoring distinguishes transit, exchange and transport faults.
The security section should cover prefix and route leak prevention, RPKI, maximum-prefix controls, blackholing, port access, management authentication, privileged consultancy access and abuse response. A blackhole test should use an isolated prefix and a written window. An exchange test should confirm one-MAC and permitted-traffic rules without disturbing other members. The customer should retain evidence that filters behave as agreed after a configuration change.
The data section should classify billing data, support records, sampled flows, routing telemetry, address-registration data and consultant access. Record retention, location, third parties and deletion duties where they matter. The Dutch company address and GDPR statement belong in this record, but they should not replace the product-specific answers.
The support section should include NOC, sales, abuse and management escalation routes; severity definitions; acknowledgement and update targets; maintenance channels; authorised customer contacts; and emergency change rules. Test the telephone and ticket path during onboarding. A polite response to a planned test provides more evidence than an untested around-the-clock claim.
Finally, write the exit before activation. State how BGP sessions are removed, how route objects and authorisations are transferred or deleted, how leased addresses are returned, how reverse DNS and geolocation are changed, how exchange ports are disconnected, how configurations and telemetry are exported, and when billing stops. For consultancy, require credential removal and documentation handover. For Layer 2, plan the parallel circuit or routed migration needed to avoid a hard cut.
This record is not paperwork for its own sake. It is the customer's control surface. It makes the network attributable, queryable and recoverable when staff, routes, facilities or suppliers change.
Bottom line
InterEdge B.V. has more verifiable substance than its compact public profile might suggest. The Dutch legal identity is tied consistently to registration number 87355299, a Brielle address and two RIPE records. AS213753 has current route, exchange and facility evidence, while AS56584 is clearly associated with Inter-IX. The company publishes a real product range, explicit BGP controls, a looking glass, NOC and abuse routes, facility presence, service prices and detailed exchange terms. These records make a serious technical conversation possible.
The limits are just as important. Most performance and scale statements come from InterEdge's own pages or self-maintained network directories. The public evidence does not show an audited uptime history, support-response distribution, customer restoration cases, complete staffing model, full route-by-route locality or an independent account of service quality. Counts for peers and facilities use different definitions, the advertised upstream list is broader than the simple RIPE policy, and the public blackhole-community documentation contains a conflicting ASN value.
None of those gaps makes the service unsuitable. They define the work a buyer must do. Confirm the contracting entity and product. Obtain the actual service-level schedule. Ask for a location-specific path and dependency design. Verify route policy, RPKI, prefix filters and communities in a controlled test. Price cross-connect, transport and operating labour alongside the port. Separate transit, exchange and Layer 2 monitoring. Contract for support and locality rather than inferring them. Design the exit before the first route is accepted.
InterEdge's strongest proposition is not that a Dutch name guarantees the edge. It is that the company exposes enough identity, network and policy detail for a customer to build an evidence-based service boundary. Whether that boundary is reliable will be decided by the signed design, the people who answer, and the records that remain correct when the network changes.