Summary

  • One RIPE NCC forum user reported empty single-IP Looking Glass results beside populated exact-prefix results, first on 24 August and again with another address on 2 September.
  • Four checks on 3 September returned data for both forms of both examples. They did not reproduce the symptom and do not establish a permanent fix.
  • An IP request includes an address-to-routed-prefix lookup. An empty answer cannot safely be treated as a route withdrawal before that step, the observation time and the collector view are understood.

The two strings are close enough to look interchangeable: 14.137.164.1 and 14.137.164.0/24. One names an address. The other names a block of addresses. In a report posted to the RIPE NCC forum on 2 September, the first yielded an empty Looking Glass result and the second yielded routes.

By the next day, that contrast was not present in our checks. At about 04:13 UTC on 3 September, both requests returned populated responses. So did the earlier pair discussed in the same thread. The strongest current statement is therefore not that RIPEstat is failing, or that it has been fixed. It is that a dated, attributed discrepancy deserves to be understood without turning it into a claim about the network itself.

A lookup before the looking glass

RIPEstat’s Looking Glass documentation explains the difference between the inputs. A prefix must match a routed prefix exactly. For an IP address, the service first tries to find the encompassing routed prefix. It can then return observations for that block. The default look-back limit excludes entries older than 86,400 seconds.

That convenience hides a consequential step. The person entering an address may think the service is asking only whether a route exists. The service must also work out which announced block to ask about. A problem in that intermediate lookup could affect the answer without changing any router’s announcements. That is an explanation of the dependency, not a finding that this particular lookup caused the reported symptom.

Nor is /24 a universal repair. An address can sit within a differently sized announced block. Supplying an arbitrary mask changes the question and may produce another empty result. A useful comparison requires a prefix established as routed, not merely a syntactically plausible block containing the address.

What the exchange actually says

The public discussion began on 24 August. The account moonteach reported the contrast for 159.138.184.0 and 159.138.184.0/24. On 25 August, ties, an account publicly marked as RIPE NCC staff, described the symptom as apparently transient, explained the longest-prefix lookup and said a colleague would be asked about handling a failed lookup.

The same reporter returned on 2 September. The earlier address now worked, the post said, but 14.137.164.1 produced an empty result while 14.137.164.0/24 produced data. The pasted query times were 27 seconds apart. These are one person’s reported examples, not simultaneous controlled measurements, a second independent report or a service-wide failure rate. The staff reply did not announce a confirmed cause or completed remediation.

Four successful checks, not a recovery certificate

Our four sequential requests ran between 04:13:08.929 and 04:13:10.945 UTC on 3 September. Each returned HTTP 200, status ok and populated data. The IP responses explicitly reported conversion to the corresponding /24; their effective resource parameters reflected that conversion.

Requested resource Collector entries Peer rows
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

These counts describe the captured responses. They are not counts of distinct network operators or a census of RIS infrastructure. Equal row totals also do not establish identical snapshots: the September example’s two latest_time values differed by 20 seconds. The links above run live queries and will not preserve these historical results.

The test is useful precisely because it limits the headline. It rules out reproducing the reported contrast in those four requests at that time. It cannot reconstruct the earlier server state, identify what changed, or show how often another address might encounter a similar symptom.

A successful request is not a successful route

The Data API’s response structure separates status, messages, version and cache information. Those fields help explain how a request was handled; they do not turn HTTP success into proof that an address is reachable. Conversely, an empty data field does not by itself prove a routing withdrawal.

RIS collects BGP observations through volunteered peer sessions. It is not an end-to-end forwarding test. Between a running network and an analyst’s conclusion sit the exporting peer, collector, query interpretation, freshness rules and response handling. A discrepancy can be investigated at those boundaries without assigning it prematurely to the network owner.

Nothing in this exchange establishes a customer outage, a hijack or a loss of traffic. Its value is smaller and more practical: it shows why the exact question belongs beside the answer. Before an empty address lookup becomes “the route disappeared”, establish which route the lookup actually asked for.