Summary

  • APNIC records AS132722 as an active autonomous-system object associated with Intellium Technology Limited. That is authoritative number-resource identity, not evidence that a route, exchange session or customer service is live.
  • PeeringDB lists two declared exchange connections for the ASN, while Intellium's website describes IT and communications services. These sources make the public identity and stated interconnection surface clearer, but they do not prove traffic, capacity, resilience or service performance.

Start with the resource that APNIC records

An autonomous system is a network, or a group of networks, that presents a common routing policy to the wider internet. Its autonomous system number, or ASN, is the unique identifier other networks use when exchanging reachability information through the Border Gateway Protocol, usually shortened to BGP.

The APNIC RDAP record for AS132722 covers exactly that number. It uses the handle AS132722 and the object name ITL-AS-AP, gives New Zealand as the country field, and marks the registry object active. Its description and registrant entry name Intellium Technology Limited. The record shows a registration event on 2 April 2013 and a last-changed event on 25 November 2020.

This is a strong answer to a narrow question: which organisation does the regional internet registry currently associate with AS132722? It also gives operators a stable public object and contact boundary when a routing or abuse issue needs to be directed to the recorded holder.

It is not a service-health reading. Active describes the administrative state of the RDAP object. It does not mean that AS132722 is announcing a route now, that another network can reach it, or that equipment and customer services are healthy. A registry is valuable when its records are unique, accurate and traceable. Asking it to prove live routing would confuse a ledger with the systems the ledger describes.

PeeringDB records declarations, not live sessions

The PeeringDB network record for AS132722 adds an operator-maintained interconnection layer. Its single row names the network Intellium Technology, links to the Intellium website, classifies it as Cable/DSL/ISP, and declares an open general peering policy.

The same row currently shows zero in its IPv4 and IPv6 prefix fields and leaves its IRR set, looking-glass and route-server URL fields empty. Those values describe the contents of this PeeringDB record. They do not establish that Intellium originates no routes, has no address resources elsewhere, or lacks IPv6 capability in every context. A directory field can be incomplete, deliberately unpopulated or maintained on a different schedule from the running network.

PeeringDB's separate exchange-connection response for AS132722 contains two declared rows. One places the ASN at APE with a listed speed of 1,000 Mbps, an IPv4 address, no IPv6 address and no route-server-peer flag. The other places it at AKL-IX with a listed speed of 10,000 Mbps, IPv4 and IPv6 addresses, and a route-server-peer flag.

These entries make the declared interconnection surface more legible. An engineer can use them to ask whether the expected ASN, exchange and address are still part of a current design. They may also help separate an identity mistake from a routing investigation.

They cannot close the investigation. PeeringDB is not a packet capture or a BGP collector. A row marked operational is not proof that a session is established at this moment. A listed port speed does not show current traffic, usable headroom during a fault or contracted capacity. An exchange address does not reveal a customer's path, the physical route to the exchange, upstream diversity, power independence or the condition of equipment behind the connection.

The company website describes a service boundary

The Intellium website presents the company as an IT support and communications provider. Its service navigation includes cloud, IT support, voice and internet, cybersecurity, productivity and business intelligence. The domain also aligns with the contact domain in the APNIC record and the website field supplied to PeeringDB.

That alignment supports a bounded identity bridge: the registry, peering directory and operator site refer to the same Intellium network context. It does not prove that AS132722 carries every service named on the site. A business can use several network resources, suppliers or delivery paths. A service page explains what the operator offers; it does not identify the route used by a particular customer or demonstrate that the service met an availability target.

The distinction protects both readers and the company from overstatement. Treating a service menu as network telemetry could falsely attribute an outage or performance result to AS132722. Treating an ASN record as proof of every service could make a sound registration entry carry claims it was never designed to support.

What the evidence can and cannot answer

The four public sources close three questions:

  1. Who is recorded for the ASN? APNIC associates AS132722 with Intellium Technology Limited.
  2. What public interconnection does the operator declare? PeeringDB lists a network record and two exchange-connection rows for the ASN.
  3. What does the company say it offers? Intellium presents IT support and communications services under its own domain.

They leave the operating questions open. The source set contains no independent BGP observation, session state, traffic measurement, route history, latency test, facility audit, customer contract or service-status result. It therefore cannot show whether a prefix is visible, whether either declared exchange connection is active, or whether a named service is reachable.

Running evidence should take priority for those questions. A current route-collector view could show whether qualifying routes are observed from stated vantage points. Session telemetry could show whether BGP is established. Interface counters could show traffic. A dated failover exercise could test continuity. Each would answer a different operational question, and each would need its own timestamp and scope.

The absence of that evidence is not evidence of failure. It is a boundary on the conclusion. The correct statement is that live routing and service performance are unproved by this source set, not that they are poor or unavailable.

Questions for operators and customers

A useful follow-up starts with the public identity and then moves toward the running system.

Operators can confirm whether AS132722 is still the expected routing identity, whether the APE and AKL-IX entries reflect the current design, and whether the listed exchange addresses remain assigned to the intended sessions. They can then check the actual route policy, session state and observed announcements rather than assuming the directory supplies those answers.

Customers can ask which ASN and delivery path serve their contracted product, which dependencies sit outside Intellium's control, and what evidence supports availability or recovery claims. If continuity matters, the relevant material is a dated test with a defined service, failure scenario and measured result—not the administrative status of an ASN.

Incident responders can use the same separation. The registry identifies whom to contact. The exchange directory suggests declared coordination points. Current telemetry determines whether the problem is routing, access, name resolution, an application dependency or something else. Keeping these layers distinct narrows the search without assigning blame from incomplete evidence.

What to watch

Several changes would justify a fresh assessment:

  • an APNIC update to the AS132722 holder, status, contacts or event history;
  • a PeeringDB change to the network identity, policy or exchange-connection rows;
  • a change in the Intellium domain or the services the company presents;
  • authoritative, time-stamped routing or session evidence that establishes the current operating state;
  • a dated customer or operator test that measures a specific service outcome.

Every observation should retain its date and source layer. A registry update, a directory declaration and a live route observation are all useful, but they are not interchangeable.

Sources

AS132722 gives Intellium Technology Limited a precise public network identity. PeeringDB adds declared exchange context, and the company website adds first-party service context. None of those records is a substitute for current routing or service evidence. Their value is greatest when each is allowed to answer the question it was built to answer—and when the unanswered operational questions remain visibly open.