Summary

  • Seattle Internet Exchange lists a $7,500 one-time charge for a 100GbE core port, with no recurring monthly port fee under that option. Getting a circuit there, arranging peering and maintaining alternative paths are separate jobs.
  • SIX publishes its connection process, three core locations and detailed route-server policies. Those documents offer a much better starting point than the supposed gaps described in an earlier version of this article.

The striking number on Seattle Internet Exchange's price list is not the speed. It is the absence of a monthly port bill after the one-time payment. A 100GbE core port costs $7,500; a 400GbE port at Westin Building or KOMO Plaza costs $15,000. That is an inviting proposition for a network with traffic to exchange in Seattle. It is not an offer of free internet access.

A port connects a network to a shared meeting place. Whether that meeting is useful depends on who else is there, which routes they will exchange, and how the network reaches the building in the first place. SIX's public documents make those distinctions unusually concrete. Follow a connection from the price list to the routing table and the real buying decision comes into view.

The invoice stops at the port

The joining instructions list one-time core charges from $100 for a first 1GbE port to $1,500 for 10GbE and $7,500 for 100GbE. The standard arrangement has no monthly recurring port charge. Operators that prefer smaller initial payments can choose a monthly option for the higher-priced ports instead: $900 a month for 100GbE, for example, with a ten-month minimum. That minimum totals $9,000, not $7,500. Further monthly contributions after the tenth month are optional at the member's request.

The exchange's fee is only one line in a connection budget. A member still needs to get its equipment or circuit to the exchange and arrange the cross-connect. SIX asks for the location, carrier or colocation provider, port speed and whether a jumbo-frame connection is wanted. It confirms the fees, issues an invoice or letter of authorization as appropriate, and supplies testing instructions before address assignment. The member or its colocation provider runs the cross-connect to the SIX panel.

That sequence matters more than an abstract question about who has control. The exchange, the member and the facility have different work to do. A letter authorizing a cable connection is not the cable, and a working cable does not establish every peering relationship.

Three core locations, more than one route into them

SIX's topology page separates switches run by its operations team from extensions run by third parties. The core is at Westin Building, KOMO Plaza and Sabey Intergate. The published uplinks from KOMO Plaza total 1.2 Tbps; those from Sabey total 300 Gbps.

An extension can bring a network to the exchange without a direct core connection. But it also introduces another operator's service. SIX charges a one-time $100 for an extension connection, while the extension operator sets its own port fees. Capabilities differ, too: the topology table identifies which extensions support jumbo frames and blackhole filtering at the switch.

Three named locations do not, by themselves, guarantee three independent paths for a particular member. Two circuits can still depend on a common cable route, building service or intermediate supplier. The public map identifies the places and links; the member's own design determines which failures it can survive.

Routes are exchanged before traffic is exchanged

The relevant routing number is not a mystery. SIX's route-server documentation explicitly gives ASN 33108, with configuration examples using the same number. It lists two route servers, rs2 and rs3, for IPv4 and IPv6 on the standard and jumbo VLANs.

A route server reduces the number of separate arrangements needed to learn routes from other willing participants. It does not carry their packets. The distinction is set out in RFC 7947: the server brokers reachability information, while traffic travels between the participants over the shared network. Losing route information can still disrupt connectivity, but that is not the same failure as every packet passing through one central router.

Nor does a route-server session make every listed network available automatically. SIX applies routing filters, honors the PeeringDB choice not to peer through route servers, and lets participants control propagation to particular peers. It checks routing-registry data and refreshes RPKI data hourly; an announcement that violates a relevant route-origin authorization is rejected.

These are not undisclosed policies awaiting discovery. The operator publishes them. It also recommends sessions with all available route servers and direct peering with important peers. The service is a supplement to direct peering, not a reason to abandon it.

A list worth using, not merely counting

The participant directory offers downloadable tables, connection information and route-server details. It links rejected prefixes to their reasons, with a separate filtering analysis page. This gives an operator somewhere to look when an announced route does not become a usable one.

It is also a reminder that a participant count is not a connectivity guarantee. A network can appear in a directory without offering the particular routes another member needs, on the terms that member wants. Checking relevant peers and actual sessions is more useful than treating every row as an interchangeable unit of value.

The same care applies to identifiers. SIX's dated machine-readable export distinguishes its standard and jumbo services and references PeeringDB records 13 and 1285 respectively. That is the operator's published mapping. Two different URLs returned during earlier research did not establish that the exchange's identity was unstable.

SIX describes itself as a non-profit exchange and publishes port and traffic figures on its website. Those figures describe the shared facility, not a member's likely savings or a guarantee of spare capacity on every link. The more useful promise is narrower: a relatively simple port-price model, supported by enough operational detail to plan a connection. Whether that connection earns its keep depends on the traffic it can actually exchange.

Corrected 24 October 2026: SIX uses ASN 33108 for its route servers, not ASN 10297. The operator publishes participant data, port information, filtering rules, connection instructions and a three-site core topology. Earlier claims of missing disclosure, unstable exchange identifiers and a demonstrated shared single point of failure were unsupported and have been removed.