Summary

  • PIT-IX's exchange record reports three facility associations, thirty-six registered networks and a forty-one-network IX-F import refreshed at 01:14 on 4 November 2026 — enough to settle that this is not a single-room club.
  • The same record names none of the three, and AS30365, the route-server ASN a member actually peers with, carries zero facility associations, zero exchange associations and no facility-association date at all.

The exchange record is not thin. It carries the name PIT-IX, the alternative PIT-IX Pittsburgh, the long name Pittsburgh Internet Exchange, the city Pittsburgh and the continent grouping North America. It reports fac_count 3, net_count 36 and ixf_net_count 41, with an IX-F import timestamp of 2026-11-04T01:14:26Z, hours old when it was read (PeeringDB exchange record for PIT-IX). It gives the media as Ethernet, unicast and IPv6 true, multicast false. It gives an open peering policy, no location requirement, no contract requirement — and, in the same breath, service level "Not Disclosed" and terms "Not Disclosed". The exchange dates itself to 2017-11-07 and was last edited on 2025-08-05.

That is an inventory, and it is a competent one. What it is not is a map.

A count of three can mean almost anything

Three facilities is a real fact and a weak one. Three cages inside one building share a power feed, a cooling plant, a fibre entrance and usually a single stretch of duct under the same street. Three separate buildings on separate utility feeds and separate cable paths behave completely differently when a backhoe finds the wrong conduit. A facility count cannot tell those two worlds apart, because the count is the same in both.

The organisation record fills in exactly one location: 1016 North Lincoln Ave, Pittsburgh, Pennsylvania 15233, at 40.450257, -80.020202, an entry created in 2017 and last touched in 2022 (PeeringDB organisation 18417). Nothing in the retained records binds that address to any of the three counted facilities. It may be one of them. It may be an office. It may be a legal seat with no switchgear behind the door. A reader cannot tell, and the record does not volunteer a guess. Both the carrier set and the campus set on that organisation record are empty, so there is not even a transport hint to work from.

The ASN a member configures has empty columns

Here is the sharper edge. A member of PIT-IX does not peer with the exchange object. It configures a BGP session to an autonomous system, and the organisation's own network list names it: AS30365, "PIT-IX Route Servers", typed Route Server, scoped Regional, associated with IRR AS-SET AS-PITIX, with prefix limits of 100,000 for IPv4 and 30,000 for IPv6 (PeeringDB organisation 18417). The network record behind that ASN points its website at the exchange and repeats the same name (PeeringDB network record for AS30365). The registry view agrees on the holder: the block 29696–30719, assigned by ARIN inside the IANA 16-bit registry, belongs to "PITIX - Pittsburgh Internet Exchange" (RIPE NCC as-overview for AS30365).

So the identity is confirmed from three directions. And on the same record that confirms it, fac_count is 0, ix_count is 0 and netfac_updated is null. The last exchange-to-network association update on that object is 2023-09-14.

A zero field is not a witness statement. It does not prove the route server sits nowhere; it proves the record makes no claim about where it sits. That distinction is the entire problem, because it is the record a prospective peer, an insurer, or a network engineer running a pre-connection check will actually read. The question that decides whether a member's traffic survives a building failure — does my route-server session depend on the same physical plant as my port? — has no answer in any field of the ASN they are told to configure.

There is a second ASN in the same organisation, and it muddies rather than clarifies: AS400798, "Pittsburgh Internet Exchange Services", created 2023-06-28, carrying ix_count 1 and fac_count 1, with an exchange-to-network update dated 2026-03-26. Which identity carries member services, and which carries the fabric, is not stated anywhere in the retained fields.

Thirty-six and forty-one

The two network counts differ by five, and nothing retained defines either count's population. A reader cannot establish whether the IX-F import includes route-server-only entries, whether one count is members and the other prefixes-adjacent sessions, or whether the gap is ordinary lag between an operator's own register and the automated feed. The IX-F timestamp is evidence that an import ran on the morning of 4 November 2026; it is not evidence of traffic, uptime, or a single member's experience (PeeringDB exchange record for PIT-IX). Recency of a file is not health of a fabric.

What a peer actually needs, and what this record withholds

Four things decide whether PIT-IX's redundancy claim can be underwritten rather than admired.

First, the names. A facility count with no addresses cannot be checked against a member's own footprint, its carriers, or the buildings its customers already sit in.

Second, whether the route-server function exists in more than one of the three. Anycast route servers and separate per-site instances are different products with different failure behaviour and different operational cost, and the record is silent between them.

Third, whether a member's port and its route-server session can be placed in different failure domains on purpose. Without that mapping, a member asking for diversity is asking for a promise with nothing behind it in writing.

Fourth, how traffic crosses between the sites, and who controls that transport. The exchange's own statistics page and its route-servers page, both referenced by the records, were not obtained for this article, and the facility rows attached to exchange 1999 were not obtained either: the three requests returned permission and capacity errors. The facility list is missing because it was not retrieved, not because anyone demonstrated it does not exist. That limitation belongs next to the finding rather than in a footnote, because it is the difference between an operator that hides its topology and a record that never asked for it.

The commercial side is blunter still. Service level and terms are both marked not disclosed. A buyer comparing interconnection options can see that PIT-IX exists, that it is open, and that it has grown past a single room. On resilience, the public record offers a number where a map is required. Until the three buildings have names and the route server has an address in at least two of them, that is the honest reading: a count, and no topology.