Summary

  • The registration under ASN 24508 is named “DE-CIX Kolkata Route Servers” — a name for the machinery that hands routes between connected networks, not for a member network. That is a different object class from an exchange record that carries ports.
  • The operator's Kolkata text invites a reader to peer if they already have a PoP in the city. The invitation is conditional, and the page as retrieved names no facility, no launch date, no member, no port and no capacity figure.
  • Two routing-statistics queries for the ASN returned nothing and three further document retrievals were refused. Those are retrieval failures, stated once here so they are not mistaken for measurements of zero.

Read the record by what it registers

The most useful fact in this file is a name, and it arrives in a database most readers will never open. The network record returned for ASN 24508 reduces to this: object id 20757, organisation id 14750, name “DE-CIX Kolkata Route Servers”, also known as “DE-CIX Kolkata”, status “ok”.

That is worth pausing on, because it is not the name a careless reader expects. It is not “Kolkata Internet Exchange”. It is named for route servers — the service, run inside an exchange, that distributes the routes members announce to each other. A route server is machinery. It has a function in a fabric the way a switch does; it is not itself a member, and it does not count members.

The second thing the record tells you is what class of object it is, and here the vocabulary matters more than the numbers. A voluntary interconnection database holds several kinds of record. A network record describes an autonomous system: its number, its organisation, its contact and policy data, its declared role. An exchange record describes a fabric: a switching platform, its physical locations, and the participants attached to it with ports and addresses. The record retrieved here is unambiguously the first kind. It carries no port count because a network record is not where a port count lives.

It carries no participant list because that is not what the schema is for.

Two opposite misreadings come out of the same document. One reader sees “DE-CIX Kolkata” and status “ok” and reports a live exchange with an active database presence. Another sees no ports and reports an empty one. Both are describing the schema they happened to fetch. Neither has seen a fabric.

What the name does establish is worth stating precisely, because it is more than any prior reading of this node had. An autonomous system is registered, under a number, to route-server machinery bearing the operator's name. If that reading is right — and it rests on the record's own self-declared naming, not on a registry holder field — then the announcement behaviour that earlier coverage treated as this node's defining fact was being measured on the machinery, and the membership question was never in play. I did not retrieve the authoritative aut-num record that would confirm who holds AS24508.

That gap belongs to the next section but one.

The invitation that assumes you already built

Now the only document in the set written for a customer to read. The DE-CIX locations page carries a Kolkata entry that does two things in a very short space, and both are more interesting than a location listing usually is.

It makes a geographic claim. Kolkata, the page says, “is the cultural capital of India with over 14 million inhabitants; it interconnects Bangladesh, Nepal, and North East India to the Internet highways.” That clause converts a point of presence in an Indian city into a regional gateway for three neighbouring jurisdictions — one of them a country of some 170 million people, another a landlocked state dependent on transit through others. I record it as the operator's assertion.

Whether networks in Dhaka, Kathmandu or Guwahati actually exchange traffic in Kolkata rather than hauling it to Mumbai, Chennai or Singapore is a routing question, and routing questions are answered by looking at where prefixes are announced and from which facilities.

Then, more revealing, it names its audience: “If you have a PoP in Kolkata, peering is the best way to exchange your data directly with other networks.” Read that condition twice. It is not “if you want a presence in eastern India.” It is that you already have one. This is not a come-here message; it is an if-you-are-already-here message, addressed to networks that have already committed a building, a rack and a circuit to the city.

That is a sane page for an operator to write, and it is not a criticism of anyone. Exchanges work this way: the parties who can reach the fabric are the parties worth addressing. But it settles what the document is evidence for. A conditional invitation proves that a commercial offer exists and that it presumes co-location already in place. It does not prove that anyone accepted the offer, and it does not describe the thing being offered at the level of detail a buyer needs.

The entry as retrieved names no facility, no launch date, no member, no port and no capacity figure — and I am describing the retained text of that page, not the whole of the operator's website, which may hold more elsewhere.

What a member count would take

Four quantities would together turn this name into a fabric: a port assignment showing that a network is attached to a named exchange LAN, a registry holder record tying AS24508 to a legal entity, a facility identity, and some traffic or member figure. None of the four is in the documents retrieved today, and it is worth being exact about why, because the reason is not that the numbers are zero.

Two routing-statistics endpoints for the ASN returned no readable content on 31 October 2026: the autonomous-system overview and the announced-prefixes list. A failed query is not a finding. It does not establish that the number announces nothing and it does not establish that no holder exists. It establishes that on that date these two layers were not observed by me.

Three further retrievals — an exchange-LAN record with port assignments, the authoritative APNIC aut-num entry, and a dedicated Kolkata location page — did not execute at all, refused upstream after repeated attempts across the day. The one document in the set that would carry assigned ports and therefore the nearest thing to a count of who is attached is the one I could not obtain. That is the whole of the retrieval debt, and I am stating it once, here, because it is a limit on this article rather than the subject of it.

What remains is a set of records individually honest and collectively thin. The operator's page asserts a role and a regional function. The peering database asserts an identity and a status. The registry queries assert nothing, having returned nothing. Records proliferate faster than measurements, for an ordinary reason: a city page costs a marketing team an afternoon, and a port count costs an operator money to publish and can embarrass it in front of a customer comparing it with a rival. The scarce item is always the measurement.

The buyer's question, and why the geography is the expensive part

The regional claim deserves more than a sceptical shrug, because if it holds it is the most consequential thing in this file, and if it does not the page is doing something ordinary that most infrastructure marketing does.

Eastern South Asia depends on a small number of international gateways. A network in Bangladesh, Bhutan, Nepal or India's north-east that wants to reach a European or American peer has a limited menu of paths, and the binding constraint is not the distance between a Dhaka router and an Amsterdam one. It is how many independent ways out of the region exist. Every additional place where regional networks can meet each other and meet international carriers shortens the path and, more importantly, changes what fails when something fails. Two networks that peer in Kolkata keep their local traffic across a cut on the Mumbai or Singapore route.

Two networks that peer only in Singapore do not.

That is a good argument for a Kolkata fabric. It is not evidence that this fabric carries it, and the commercial difference is concrete. A regional ISP weighing a port is not buying a story about Bangladeshi path diversity. It is buying a physical port on a switch with a capacity commitment and a contract term, and before it signs it wants to know how many other networks are already on that switch — because an exchange with few members is a monthly bill rather than a peering strategy. Nothing in the records retrieved today lets that ISP count them.

That is the practical stake, stripped of commentary. The buyer's question is unanswered by the documents available, and the seller's page is written on the assumption that the buyer has already decided. For an analyst tracking South Asian interconnection, the discipline is to keep three quantities apart that marketing prose fuses: the existence of a commercial offer, the existence of a switching platform, and the existence of traffic. Only the third is an interconnection measure, and it is the one least often published anywhere.

What this record leaves open

On the dated evidence examined here, DE-CIX Kolkata is a name with two substantiated supports: a registered route-server identity under ASN 24508, self-declared in a voluntary database and marked “ok”, and an operator page that places the city in a regional geography and offers peering to networks already present there.

What is not established in the same window: whether AS24508 is attached to any exchange LAN with assigned ports; who holds the number according to the authoritative registry; whether any member network is present at a Kolkata facility; how many ports are lit; what capacity they carry; which building the fabric sits in; or when it began operating.

The second list is longer than the first, and no additional prose will shorten it. What can be said with confidence is narrower and more useful than the framing this publication used in October: an autonomous system that does not originate prefixes under its own number is not thereby an exchange without participants, and an exchange with participants is not thereby an originator. Those are two instruments reading two quantities, and conflating them was the error worth correcting.

The reading above has a clean falsifier. One exchange-LAN record listing assigned ports against a Kolkata fabric would move this node from name to facility, and I would rather it appeared: a measured fabric in a region with few gateways is a better story than a thin one, and considerably more useful to the operators who have to choose where to build. Until then, the honest description of eastern India's local exchange question is that the documents available answer a different question than the one being asked. The reader who wants to know whether the fabric exists still cannot find out from this.

The reader who wants to know why that is hard to find out now has a worked example.