Summary

  • The registry record for the Pittsburgh Internet Exchange now resolves its three facility associations to three different operators — Crown Castle Inc., EdgeConneX Inc. and DataBank, Ltd. — which is precisely the detail a 4 November reading of the same record could not obtain.
  • The exchange LAN row names the LAN “Peering-1500”, sets an MTU of 1500, turns 802.1Q off and sets rs_asn to 0, while the one participant row read in full records route-server peering on that LAN. A prospective member can see that route-server peering happens, and cannot see from the LAN row which ASN supplies it.
  • Nothing read on 12 November quantifies traffic volume, latency saved, port capacity, uptime, service level, terms or price, and no western Pennsylvania access network is identified among the 36 counted networks.

The exchange record for id 1999 reports 36 registered networks, three facility associations, an IX-F import stamped 2026-11-12T00:12:32Z — roughly twenty hours older than the read itself — and “Not Disclosed” in both the service-level and the terms field. Two of those figures are ones an outsider can act on. Neither is a performance number.

The facility set carries three entries, ids 1423, 1925 and 4292, attributed to Crown Castle Inc., EdgeConneX Inc. and DataBank, Ltd. Three entries, three distinct operators, one for one. That is a stronger diversity reading than the bare count of three, because it is not three cages inside one landlord’s building. It is still not a topology: the record does not pair any member with any operator’s facility, and it does not say how many distinct physical paths those three represent.

The LAN row is where the record stops being a brochure. The LAN is called “Peering-1500”, the MTU is 1500, 802.1Q support is false, and rs_asn reads 0.

One participant row was read in full from the participant listing: netixlan 39041, network 4224, AS13335, LAN “PIT-IX: Peering-1500”, speed 100000 — the registry reads that field in megabits per second, so 100 Gbps for this member — is_rs_peer true, bfd_support false, operational true, IPv4 206.71.141.11 and IPv6 2001:504:77::11.

Read the two rows together. A member records that it peers with the route server on that LAN. The LAN row itself designates no route-server ASN. Zero in an AS-number field is an absence of designation, not proof that no route server runs, and the organisation record settles that: it carries a network object named “PIT-IX Route Servers” on AS30365, alongside “Pittsburgh Internet Exchange Services” on AS400798. The live member signal is the stronger evidence that the function exists. The empty field is the more interesting one, because it is the field an automated peer would consult — a network provisioning from the registry rather than from an email thread.

The operator’s own page makes the case it wants members to buy, in its own words: peering “enables connected organizations to offer stable, fast, and cost-effective Internet services to their end-users and customers”, and “allows Pittsburgh sources and destinations to communicate directly within the region, rather than traveling long distances to needlessly bounce through another city”, tagged #KeepTrafficLocal. The same page describes PIT-IX as a neutral and independent exchange and a non-profit IRS 501(c)(6) organization, and sends readers to “Access PIT-IX at any of the member data centers” — naming none of them in the passage read.

This corrects a piece published here on 4 November: the earlier reading counted the three facility associations and could name none of them. The change is in what could be retrieved, not in what the operator chose to publish. Those three entries were in the record’s facility set all along.

So a network weighing a Pittsburgh port can now answer the question that decides where it racks — who owns the floor space — and still cannot answer the questions that decide the deal: which venue for which member, what a port costs, what service level is committed in writing, and who on the other side of that fabric is actually in western Pennsylvania. The slogan is intent. The record is a map of venues.

What the record now lets you check

Five things, and they are worth listing because each one used to be either unavailable or easy to get wrong.

  • Venue ownership. Three facility entries, three named operators, three separate organisations behind them. A prospective member can ask about a specific operator’s house instead of asking about “the member data centers” in the abstract.
  • LAN identity and frame handling. The fabric is named, and its MTU and 802.1Q settings are published. A network planning jumbo frames or VLAN hand-off learns here that neither is on offer on this LAN as recorded.
  • Route-server presence. Visible twice over: a member row flagging route-server peering, and an organisation-owned network object on AS30365 named for the function.
  • Registry freshness. The IX-F import timestamp gives the count an age. On 12 November that age was about twenty hours.
  • Participant detail. For at least one member, ASN, LAN, speed, IPv4 and IPv6 addresses, route-server flag, BFD flag and operational state are all readable.

What it still cannot

Nothing in the pages read states traffic volume, latency saved by local peering, total port capacity, utilisation, uptime history or price. The record’s own commercial fields are the emptiest part of it: service level and terms both read “Not Disclosed”.

No member among the 36 counted networks is identified as a western Pennsylvania access network. That is an absence from the rows read, not proof that none exists: of 36 counted networks, exactly one participant row was read in full, and the registry’s own summary names a further handful of ASNs. Those are aggregates, not rows inspected, and no claim about the composition of the member set follows from them.

The route-servers page did not return on either attempt on 12 November, so this article asserts nothing about its policy, its instance count or its pricing — and denies nothing either. The 501(c)(6) status is the operator’s self-description on its own page, not a filing read here. And “facility” remains the record’s word: calling these three entries buildings or campuses would claim more than the vocabulary supports.