Summary

  • BTW’s published Directory projection associates EBL Al Lawn Al Akhdar International Company for Communications and Information Technology Ltd. with AS211513, but that association is not by itself proof of present routing activity.
  • The available research record does not independently verify the current holder identity, BGP visibility, originated prefixes, routing neighbours, upstreams, peers, or PeeringDB presence for AS211513.
  • The correct operational conclusion is not that AS211513 is active or inactive. It is that the evidence boundary remains open and requires timestamped, independently retrievable routing data.

The first question is not “what network does AS211513 operate?”

It is tempting to begin with the ASN and work outward: find the holder, list the prefixes, identify the upstreams, then infer the network’s commercial or operational importance. That sequence is useful only when each layer is actually observed.

For AS211513, the available public record supports a narrower starting point. BTW’s Directory projection is published under the name EBL Al Lawn Al Akhdar International Company for Communications and Information Technology Ltd. Its object card maps the company to AS211513 and describes that relationship as grounded in public autonomous-system evidence. The directory also records explicit gaps: no verified company website or public-facing presence beyond registry data, no known geography, no verified PeeringDB entry, and no confirmed contacts, customers or service descriptions. [https://stat.ripe.net/data/as-overview/data.json?resource=AS211513] [https://stat.ripe.net/data/routing-status/data.json?resource=AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513]

That is an administrative and evidentiary statement. It is not a complete operating profile.

An autonomous system number is a routing identifier. A registry record can associate an ASN with a named organisation. Neither fact, standing alone, answers the questions an operator or investor would normally ask: Is the ASN visible in BGP now? Which prefixes are observed? From which collectors? Are the paths persistent? Which adjacent ASNs appear in those paths? Does a public exchange or transit record corroborate the topology? Is the named organisation the current controller, a historical registrant, an administrative contact, or an operating network?

Those questions require different evidence.

Three layers that should not be collapsed

The first layer is administrative attribution. The RIPE Database aut-num endpoint is the relevant public registry source for checking the object associated with AS211513, its registered attributes and any declared routing-policy fields. [https://rest.db.ripe.net/ripe/aut-num/AS211513.json?unfiltered] A registry object can be authoritative for what has been recorded in the database while remaining insufficient to establish that the same arrangement is current in the forwarding plane.

The second layer is observed routing. RIPEstat provides separate data products for AS overview, routing status, announced prefixes, ASN neighbours and BGP state. [https://stat.ripe.net/data/as-overview/data.json?resource=AS211513] [https://stat.ripe.net/data/routing-status/data.json?resource=AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513] [https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS211513] [https://stat.ripe.net/data/bgp-state/data.json?resource=AS211513] These sources are designed to answer questions about what route collectors observe during a stated interval. Their evidentiary value is therefore temporal and observational. A route seen by collectors is not the same as a permanent ownership claim. A route not seen during a limited interval is not necessarily proof that an ASN has never operated or cannot operate.

The third layer is operational significance. Even verified BGP visibility would not, by itself, establish customer numbers, traffic volumes, service quality, physical location, contractual relationships or criticality. Those conclusions require additional evidence: operator statements, technical measurements, incident records, facility or exchange information, commercial disclosures, or sustained historical observations.

This separation is not pedantic. It prevents a familiar analytical error: turning a registry label into a claim about control, then turning a route observation into a claim about business scale.

What the current record actually says

The current research record states that live endpoint response bodies, HTTP statuses, cache times and observation timestamps for the requested routing and registry sources were unavailable in the research environment. The resulting fields for holder identity, announced status, prefix lists, routing state, neighbouring ASNs, BGPView relationships and PeeringDB status therefore remain unverified. [https://api.bgpview.io/asn/211513/prefixes] [https://api.bgpview.io/asn/211513/upstreams] [https://api.bgpview.io/asn/211513/peers] [https://www.peeringdb.com/api/net?asn=211513] [https://www.peeringdb.com/asn/211513] [https://www.bgp.tools/as/211513] [https://bgp.he.net/AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513]

That limitation has a precise meaning. It means the report cannot responsibly publish a current prefix count, name a present upstream, describe a peer relationship, or state that AS211513 is either announcing or not announcing routes on the basis of this record alone.

It does not mean AS211513 has zero prefixes. It does not mean that the ASN is dormant. It does not mean that no PeeringDB record exists. It does not mean the Directory association is false. It means those propositions have not been independently verified within the available evidence.

The difference between “not observed” and “observed as absent” is especially important in routing analysis. A failed or unavailable retrieval produces an evidence gap. An empty response returned by a named endpoint at a timestamp is a different kind of fact. A route collector that reports no route during a defined interval supplies a bounded observation. A research process that cannot retrieve the endpoint supplies no equivalent observation.

Why declared policy is not a live session

Registry records often contain import and export policy declarations. These fields are valuable because they show what an operator or maintainer has recorded as routing intent. They are not a substitute for live session evidence.

A declared policy may be stale, incomplete, broader than the relationships visible in route collectors, or written for an arrangement that has since changed. Conversely, an observed path can demonstrate adjacency without establishing the commercial terms behind it. An ASN immediately next to another ASN in an AS path might reflect transit, customer-provider structure, a route server, a sibling arrangement, traffic engineering, or a path artefact. The path is evidence of an observed topology at a particular vantage point; it is not automatically evidence of a contract.

For that reason, any future report on AS211513 should present registry policy, collector-observed adjacency and inferred relationship labels as separate columns of evidence. The first answers what has been registered. The second answers what has been seen. The third is an interpretation that requires methodological caution.

Independent routing databases can help with cross-checking. BGPView offers separate endpoints for prefixes, upstreams and peers. [https://api.bgpview.io/asn/211513/prefixes] [https://api.bgpview.io/asn/211513/upstreams] [https://api.bgpview.io/asn/211513/peers] Those classifications are useful candidate evidence when a current response is available, but they should not be promoted into confirmed commercial relationships without corroboration. The same discipline applies to bgp.tools and the Hurricane Electric BGP Toolkit: their snapshots can provide independent comparison, while differences in timing, collector coverage and relationship methodology can explain disagreement. [https://bgp.he.net/AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513]

PeeringDB answers a different question

PeeringDB is often treated as a shorthand for network legitimacy or physical presence. It is better understood as operator-supplied context. A current network record may provide useful information about a network name, policy, facilities, internet exchanges and peering intentions. It still does not prove that a particular BGP session is active at the moment of publication.

The converse matters as well. The absence of a retrieved PeeringDB record would not prove that an organisation has no interconnection, because participation can be incomplete, records can be stale, and not every operating relationship is represented there. The relevant endpoint for checking the current state of a network object associated with AS211513 is the PeeringDB API lookup. [https://www.peeringdb.com/api/net?asn=211513] The available research record does not contain a verified response from that lookup.

That leaves a practical rule for operators: treat PeeringDB as corroborating evidence about declared intent and context, not as a complete inventory of routing operation.

What this means for network operators

The immediate operational consequence is limited but real. AS211513 should be treated as an unresolved monitoring subject rather than assigned an unverified role.

A network operator considering filters, route-policy review or incident triage needs timestamped facts. The minimum useful follow-up would include a current RIPE Database object, a current RIPEstat AS overview and routing-status response, the announced-prefixes result, ASN-neighbour and BGP-state observations, and independent comparison with BGPView. [https://rest.db.ripe.net/ripe/aut-num/AS211513.json?unfiltered] [https://stat.ripe.net/data/as-overview/data.json?resource=AS211513] [https://stat.ripe.net/data/routing-status/data.json?resource=AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513] [https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS211513] [https://stat.ripe.net/data/bgp-state/data.json?resource=AS211513] [https://api.bgpview.io/asn/211513/prefixes] [https://api.bgpview.io/asn/211513/upstreams] [https://api.bgpview.io/asn/211513/peers]

The collection should preserve retrieval times and the exact endpoint responses. A second observation taken later is not a replacement for the first; it establishes a new point in the timeline. Repeated observations can then distinguish a transient announcement from a persistent operating footprint.

Security analysts should also avoid treating an unverified organisation-to-ASN mapping as evidence of maliciousness or benignity. If a prefix associated with AS211513 appears in an incident, the relevant questions are the prefix’s route history, origin consistency, RPKI state, path changes, announcing vantage points and incident timing. The company name in a registry record is context, not a verdict.

Investors and infrastructure readers face a similar constraint. There is currently no verified basis in this record for estimating AS211513’s capacity, traffic, customer dependence, geographic reach or revenue relevance. A public ASN association may be worth monitoring, but it is not a proxy for scale.

What would change the assessment

Several forms of evidence would materially narrow the uncertainty.

First, a current RIPE Database response could confirm the exact aut-num identity, organisation references, status and last-modified information as recorded by the registry. That would strengthen the administrative layer without, by itself, proving live operation. [https://rest.db.ripe.net/ripe/aut-num/AS211513.json?unfiltered]

Second, a timestamped RIPEstat response could establish whether collectors observed AS211513, which prefixes were associated with it during the observation interval, and which ASNs appeared adjacent in the available paths. [https://stat.ripe.net/data/as-overview/data.json?resource=AS211513] [https://stat.ripe.net/data/routing-status/data.json?resource=AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513] [https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS211513] [https://stat.ripe.net/data/bgp-state/data.json?resource=AS211513]

Third, agreement or disagreement across BGPView, bgp.tools and the Hurricane Electric toolkit could reveal whether a finding is robust across datasets or specific to one methodology. [https://api.bgpview.io/asn/211513/prefixes] [https://api.bgpview.io/asn/211513/upstreams] [https://api.bgpview.io/asn/211513/peers] [https://bgp.he.net/AS211513] [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS211513]

Fourth, a current PeeringDB record or a direct operator statement could add context about facilities, exchange participation, policy and intended interconnection. It would still need to be distinguished from proof of a live session. [https://www.peeringdb.com/api/net?asn=211513] [https://www.peeringdb.com/asn/211513]

Finally, company-level evidence would be needed to connect the network-resource record to operating reality: an official website, service documentation, regulatory filing, customer-facing announcement, technical contact, or other independently attributable statement. The Directory projection itself records that these areas remain data gaps. [https://stat.ripe.net/data/as-overview/data.json?resource=AS211513]

The bounded conclusion

The strongest defensible conclusion is deliberately narrower than a network profile.

BTW’s published Directory projection associates EBL Al Lawn Al Akhdar International Company for Communications and Information Technology Ltd. with AS211513. The available research record does not independently verify the current legal holder, controller or operator relationship; it does not verify present BGP visibility, prefixes, neighbours, upstreams, peers or PeeringDB status; and it does not establish the operational scale or criticality of any activity.

That is not an empty finding. It identifies exactly where administrative attribution stops and operational proof must begin.

For now, AS211513 belongs on a watch list for evidence collection, not in a narrative about active service, dormant capacity or commercial reach. The next useful update is not a stronger adjective. It is a timestamped response that can be inspected, compared and placed on a routing timeline.

Sources and evidence boundary