A New Network Edge: Transit, BGP, IPv6, and Remote Peering
How Helixrack moved to dedicated transit, BGP, provider-independent IPv6, optional routed IPv4, and remote peering in 2024.
- Published
- Filed under
- network
On September 18, 2024, Helixrack turned up a new network edge: 1Gbps dedicated transit, its own autonomous system number, BGP, a provider-independent IPv6 /48, and remote peering to DE-CIX New York through an upstream New Jersey access point.
The change gave the operation a more deliberate routing foundation. It did not turn a small facility into a carrier hotel, and it did not create a direct cross-connect to DE-CIX. The distinction matters both technically and in how the network should be drawn.
What came before
Helixrack began with a provider-assigned IPv4 /28. The facility allocation expanded to a provider /27 on November 30, 2023. Customers received one public /32 on a dedicated VLAN; no customer received the facility’s full provider block.
That design made early service possible, but it tied addressing and routing closely to the access provider. The September 2024 project separated several functions that had previously traveled together.
What changed at turn-up
The new 1Gbps dedicated transit circuit became the production upstream. Helixrack established BGP using its autonomous system number and announced provider-independent IPv6 space. The IPv6 /48 allowed a /64 to be assigned per customer without treating addresses as a scarce add-on.
For IPv4, Helixrack leased a routed pool from its upstream. Existing single-address services could remain on /32 assignments, while eligible plans could add an optional routed /29. The exact prefix, route filters, neighbor addresses, credentials, communities, and management design are intentionally omitted from the public article.
The original 500/500Mbps business circuit remained available for management and failover. “Failover” should not be read as a blanket availability guarantee: the source ledger must show what routes and services could move, how the path was tested, what manual steps remained, and how stateful customer traffic behaved.
Remote peering, accurately drawn
The peering path reached DE-CIX New York remotely through the upstream’s New Jersey access point. It was not a physical DE-CIX port or cross-connect installed inside Helixrack’s Elizabeth facility. A public diagram should therefore show three distinct relationships: Helixrack to its upstream in New Jersey, the upstream’s remote path to the exchange, and exchange reachability in New York.
DE-CIX maintains a current New York topology page. It is useful for explaining the exchange’s present footprint, but it is not evidence that Helixrack’s session became active on September 18, 2024. Only the 2024 provider records, route observations, and monitoring logs can support that date.
What customers gained
The practical changes were clearer address allocation, a path to customer IPv6 /64s, optional routed IPv4 /29s, and a network edge that Helixrack could operate with BGP policy rather than a single provider-default route. The final article should document when each feature became orderable; turn-up and general customer availability may not be the same date.
It should also publish measured results only from approved baselines: throughput test method, latency destinations, packet-loss window, route visibility, and failover behavior. “Faster” and “more redundant” are not self-proving claims.
The best account of this milestone is deliberately unglamorous. It names the circuit, routing model, address policy, and remote-peering relationship accurately, while keeping exploitable configuration private. A trustworthy network update tells customers what changed without pretending that every internal detail belongs on the public internet.
Sources
- DE-CIX New York topology July 14, 2026 · verification