Summary

  • Megaport’s recommended redundant IX configuration uses two separate Ports, two customer-side Layer-2 domains and peering to both route servers. Each protects a defined layer; none alone proves that the transport paths to the exchange are physically and operationally independent.
  • Remote access changes the delivery chain. Megaport can extend an IX over its software-defined network, while AMS-IX distinguishes direct colocation, its transported EasyAccess offer and connections arranged by reselling partners.
  • A buyer should count a second path only after mapping the complete chain and observing a named fault remove one service while the other continues to carry the intended routes and traffic.

Two green services, one hidden port

Imagine a network dashboard showing two remote-peering services to the same exchange. Both are provisioned. Both BGP sessions are established. A procurement sheet therefore marks the design redundant.

Now trace the services toward the customer edge. If both terminate on the same physical router, the router is one failure domain. If they use different VLANs but one Megaport Port, the port is another. If two ports sit in one chassis, room or power domain, separation may stop there. Farther along, two logical services may cross the same metro path or converge at the same exchange handoff. The service objects remain separate even when a single fault can remove them together.

This is not an allegation about any particular Megaport path. The cited sources disclose no buyer’s underlay. It is the reason a portal state cannot carry more meaning than it contains.

Megaport describes MegaIX as a virtual exchange embedded in its global software-defined network. Customers can reach exchanges in the same city or remote exchanges, and remote access can be delivered by a VXC from an on-net location. The appeal is real: the buyer can add, move or resize a peering service without ordering a new cross-connect and router at every destination. But the removal of a local cross-connect from the order does not remove physical transport from the service. It changes who supplies and observes it.

AMS-IX makes that change visible in its own connection guidance. A direct customer connects at a listed colocation and may order a cross-connect. EasyAccess includes IP transport arranged by AMS-IX. A partner connection is arranged through a chosen reseller. Those are three different delivery arrangements. The cited guidance does not establish who owns the fabric or the transport path.

Redundancy has layers, not a single label

Megaport’s IX documentation supplies a useful minimum design. Its recommended redundant configuration uses two separate Ports. Each IX service peers with both route servers, and each customer router operates in a separate Layer-2 domain. Megaport warns against putting the customer routers on one switched Layer-2 network and against pairing two services with only one route server.

Those requirements should not be diluted. Two services on one port are not the documented redundant pattern. Two routers bridged into one Layer-2 domain can reproduce loops or common failure. Two IX services that depend on one route server leave a control-plane concentration that the supported design explicitly avoids.

Yet the converse is also important. Meeting those logical conditions does not reveal whether the two ports enter different devices, buildings or power zones; whether the transport uses distinct fibre, carriers or metro routes; whether a partner handoff is shared; or whether one operational team can change both services at once. The public redundancy page does not claim to disclose those buyer-specific facts.

The result is a stack of separate assurances. Customer-router independence concerns the buyer’s equipment. Port independence concerns the access edge. Layer-2 isolation concerns the broadcast domain. Route-server redundancy concerns multilateral BGP availability. Transport independence concerns the path between customer and exchange. Handoff, site and power independence concern the physical places where those layers meet. Operational independence concerns maintenance, credentials, automation and incident authority. A design can be strong in six columns and blank in the seventh.

A live BGP session proves less than a working service

Megaport distinguishes multilateral peering through its two route servers from bilateral peering with another participant. An established session is valuable evidence: it shows that the relevant adjacency can form at that moment. The looking glass adds a view of routing state. Neither record describes the complete physical path.

Megaport’s troubleshooting guidance illustrates why. An IX incident can involve interface errors, optics or cabling, MTU, LACP, VLAN assignment, IP configuration, routing tables, reachability to a route server or bilateral peer, or a BGP protocol error. The guidance asks operators to test both devices and end-to-end connectivity. A session that remains established while traffic is black-holed elsewhere is not the accepted service outcome. A session that drops also does not identify the failed layer by itself.

Route acceptance adds another distinction. Two sessions can receive different useful prefixes because the counterparties, bilateral policies or multilateral route set differ. This article does not judge the route server’s redistribution policy; that is a different commission. It asks whether the path carrying whatever routes were accepted survives the failure that the buyer claims to cover.

Capacity and performance cannot be inferred either. A standby connection may be logically independent but too small for displaced traffic. The cited pages provide no buyer’s committed rate, congestion record, latency budget or failover result. “Connected” must therefore remain separate from “able to carry the required traffic after the other service fails.”

The source boundary is part of the answer

APNIC’s RDAP record identifies AS133937 as MEGAPORTPTYLTD-AS-AP, with an Australian country code and APNIC registry service. That record supports the linked network identity. It does not prove that this ASN carries a given buyer’s exchange service, that a route is preferred, or that two underlays are diverse.

Likewise, vendor phrases such as “remote”, “carrier-grade”, “redundant” and “total routing control” describe product intent or documented configurations. They should remain attributed. None of the cited sources discloses a named buyer’s Port IDs, VXC paths, cross-connects, buildings, carriers, power feeds, partner handoffs, maintenance domains, SLA claims or exercises.

That absence is not a reason to assume the worst. It is a reason to request the evidence object that the decision needs.