AS329678 turns one Libyan IPv4 allocation into four

Summary

AFRINIC records AS329678 and the active 102.203.196.0-102.203.199.255 allocation under organisation handle ORG-HSAC1-AFRINIC, providing an exact public number-resource identity for High Speed Access Company for Telecommunication and Technology.
RIPEstat observed four IPv4 /24s from AS329678 at the captured 28 July 2026 snapshot, covering 1,024 addresses. The routes were visible to 328 of 329 full-table IPv4 RIS peers, while no IPv6 origin appeared.
The covering 102.203.196.0/22 exists in AFRINIC registry data, but the running BGP surface consists of four /24s. That distinction separates allocated address space from the routes actually exposed to the Internet.
RIPEstat observed AS21003 and AS37284 as routing neighbours. The two logical relationships do not prove independent contracts, diverse physical paths, sufficient failover capacity or a resilient access network.
A bounded RPKI query found a valid origin result for 102.203.196.0/24. It does not establish the validation state of the other three /24s and says nothing about service availability or physical continuity.

The public network begins with a clean numerical boundary

The most useful fact about AS329678 is not its size. It is the unusually clean boundary between an allocated block and the routes currently visible from it. AFRINIC's RDAP service records an active autonomous-system entity for 329678 under organisation handle ORG-HSAC1-AFRINIC. A separate RDAP response assigns the same handle the contiguous IPv4 range from 102.203.196.0 to 102.203.199.255 in Libya. The range contains 1,024 addresses and can be expressed as the covering prefix 102.203.196.0/22.

That registry pair gives the company a public responsibility surface. Other operators can refer to a unique ASN and a specific address allocation instead of relying on a broad trading description. The two records also reduce the risk of borrowing routes from another company with a similar name: the ASN and IPv4 entities share the same AFRINIC organisation handle, while RIPEstat names the holder as High Speed Access Company for Telecommunication and Technology.

The clarity is administrative, not operational. An organisation handle does not prove which legal company signs customer contracts, owns access equipment or employs the people who repair it. An active address allocation does not show whether every address is in use, whether users receive public addresses, or whether the company operates the physical links that carry the traffic. Registry identity is the beginning of the inquiry because it makes the resource accountable. It is not the end of the inquiry.

The dates reinforce that distinction. AFRINIC records the ASN on 9 December 2025 and the IPv4 allocation minutes earlier on the same day, with both entities last changed on 16 December 2025. Those timestamps mark changes in the public registry. They do not mark company incorporation, commercial launch, first customer activation or the commissioning of any access network. The routing system supplies a separate clock.

This separation between the ledger and the running network is central to the company's public profile. The registry tells readers what is uniquely assigned and to whom the registry points. BGP tells them which parts of that assignment are currently being announced. The physical and commercial service sits behind both layers and requires different evidence.

One /22 in the registry becomes four /24s in BGP

AFRINIC's allocation spans a /22, but RIPEstat's announced-prefixes response lists four more-specific routes: 102.203.196.0/24, 102.203.197.0/24, 102.203.198.0/24 and 102.203.199.0/24. Together they cover exactly the same 1,024 IPv4 addresses as the registered range. In the captured observation window, each /24 appears from 14 July through 28 July 2026.

RIPEstat's routing-consistency view preserves the difference between the two layers. The covering 102.203.196.0/22 is present in AFRINIC WHOIS or IRR data but is not observed as a BGP route in the snapshot. Each of the four /24s is present in both BGP and AFRINIC registry data. The allocated block and the announced routes are therefore aligned in total address space without being identical entities in the route table.

There are practical reasons an operator might announce more-specific routes. Separate announcements can support routing policy, traffic engineering, selective propagation or operational segmentation. They can also make each quarter of the allocation independently visible to external networks. None of those possibilities can be selected as the actual explanation from the public data alone. The route table shows the outcome, not the operator's internal design or commercial intent.

The split matters during a fault. One /24 could disappear while the other three remain visible. A policy change could affect one route and not the rest. An origin error might be confined to one quarter of the allocation. Conversely, all four routes could still depend on one router, one circuit, one building or one upstream transport path. Four BGP objects do not automatically create four failure domains.

This is why prefix counting needs context. Saying that AS329678 originates four prefixes is accurate. Saying that it has four independent networks, four access regions or four redundant paths would be speculation. The public surface is four routing units that collectively represent one AFRINIC allocation. The relationship between those units and the customer-facing network remains undisclosed.

A recent registry entry already has broad route visibility

RIPEstat marks AS329678 as announced in its AS overview and reports four originated IPv4 prefixes in routing status. At the captured query time of 28 July 2026 at 16:00 UTC, 328 of 329 full-table IPv4 RIS peers saw the origin. That is a broad collector view for a number-resource identity that appeared in AFRINIC's registry less than eight months earlier.

The numerator and denominator are important. The statement is not that every network, customer or application could reach every address. It is that 328 of the 329 full-table IPv4 peers counted by RIPE RIS had a route to prefixes originated by AS329678 in the snapshot. RIS peers are global observation points, not a complete census of access networks, enterprise firewalls, recursive resolvers or end-user devices.

Broad propagation is still operational evidence. It shows that the ASN is not merely a reserved number or an unused registry entity. External routing systems accepted and carried its announcements across nearly the entire sampled full-table set. If a later snapshot showed a sharp visibility decline, an origin change or a complete withdrawal, observers would have a measurable event to investigate.

Visibility cannot serve as a service-level metric. A route may remain present while packet loss, congestion, DNS failure, server failure or access-network faults make a service unusable. BGP can show a path even when the path is inefficient or when the last mile has failed. The collector figure says that routing information propagated; it does not certify the performance of traffic that follows it.

The one missing RIS peer should not be overinterpreted either. Collector sessions change, policies differ and individual observation points can temporarily lack a route that is widely present elsewhere. The accurate description is a dated 328-of-329 measurement. "Globally available," "fully reachable" and "universal coverage" would turn a routing observation into a promise the data cannot support.

The routing clock starts after the allocation clock

AFRINIC's registration dates and RIPEstat's first-seen field describe different events. The allocation and ASN were registered on 9 December 2025. Routing status says AS329678 was first seen originating 102.203.198.0/23 on 8 January 2026. That gap is consistent with a resource being recorded before a route becomes visible, but it does not reveal what happened during the intervening month.

The first-seen prefix is also different from the current four-/24 shape. RIPEstat's current last-seen entry names 102.203.196.0/24 at midnight UTC on 29 July 2026, while announced-prefixes lists all four /24s across its current interval. The public routing presentation therefore appears to have evolved from an observed /23 to the present set of /24s. A complete change history would require additional dated observations; the current endpoints establish only the recorded start and present shape.

That evolution is worth monitoring because route granularity can be operationally significant. An operator may introduce more-specifics to change policy, isolate incidents or manage traffic. A new prefix pattern can also appear because a collector learns routes differently. The public data does not identify the intent, so the responsible approach is to record the change before explaining it.

The two clocks prevent a common error in infrastructure reporting. Registry creation is not commissioning. A resource can be assigned before it is used, and a route can be visible before customer service is commercially available. Equipment may be installed but not energised; links may be lit but not sold; a route may be accepted while access systems remain under construction. None of these milestones follows automatically from the date of an RDAP event or a BGP observation.

For AS329678, the strongest chronological statement is modest: AFRINIC recorded the resources in December 2025, RIPE RIS first saw an origin in January 2026, and four /24s were visible in the July 2026 snapshot. Commercial and physical milestones remain outside the source set.

Two observed neighbours define a boundary, not a resilience score

RIPEstat's AS-neighbours response lists AS21003 and AS37284 as the two observed left-side neighbours of AS329678. Routing status independently reports two observed neighbours. The agreement gives readers a compact view of the public routing boundary: four prefixes leave AS329678 through paths in which those two autonomous systems appear adjacent in the collector data.

The neighbour label is deliberately narrower than "upstream provider." BGP paths can reveal adjacency without publishing the commercial relationship behind it. A neighbour can be a transit provider, a customer, a peer or another arrangement. The captured endpoint places the two ASNs on the left side of AS329678 and reports no right-side neighbours, but that classification remains an observation derived from paths rather than a contract.

The routing-consistency response adds a useful complication. AS21003 and AS37284 are seen in BGP, yet the endpoint does not find them in registered import or export policy for AS329678. That does not make the observed paths illegitimate. It shows that the running relationship surface is richer than the registered policy surface available to this query. Policy records can be incomplete, private, simplified or stale.

Two logical neighbours do not prove physical diversity. Both sessions might traverse one transport provider, one duct, one building, one power domain or one router. They might have genuinely separate paths and facilities. The public route table cannot distinguish those designs. Nor can it show whether either path has enough spare capacity to carry traffic when the other fails.

The observed pair is therefore an accountability question, not an answer. Are the relationships commercial transit, peering or another form of handoff? Where do they terminate? What common physical dependencies exist? Does routing policy move traffic automatically, and has the alternate path been tested under load? A customer considering continuity should ask those questions rather than treating the number two as a resilience certificate.

Running code and registered policy do not fully align

The difference between observed neighbours and registered policy deserves attention because it illustrates why network research needs more than one public record. AFRINIC provides the number-resource ledger. RIPE RIS observes routes and paths. IRR-style policy data records intended relationships when operators publish them. Each layer can be accurate within its purpose while leaving gaps relative to the others.

For AS329678, the four /24 route objects align well: they are visible in BGP and present in AFRINIC's registry data. The covering /22 appears only in the registry. The neighbour relationships align less completely: AS21003 and AS37284 are visible in BGP but not in the import and export policy fields returned by the consistency endpoint.

This is not evidence of wrongdoing or misconfiguration. Many networks do not maintain exhaustive public policy entities, and private arrangements need not be fully disclosed. It is evidence that a reader should not reconstruct the complete operating design from registry text alone. Running-code primacy means the observed BGP path deserves weight when it contradicts an assumption based on static policy.

The reverse warning also applies. Collector data is not omniscient. A backup session used only during failure may not appear. Selective advertisements can hide relationships from many observation points. Route servers and private interconnections can complicate simple adjacency labels. Running evidence shows what was visible, not every configured or contractual possibility.

The useful conclusion is a bounded one. AS329678 has two observed routing counterparties in the current view. Its public registered policy does not independently document those relationships in the endpoint used here. That gap belongs in due diligence and monitoring. It does not justify guessing the contracts or treating the registry as a performance authority.

Four /24s still count addresses, not customers

The current origin set covers 1,024 IPv4 addresses. That arithmetic is exact because the four /24s partition the registered /22. The number of customers, devices or services represented by those addresses is unknowable from BGP.

A public IPv4 address can identify a router interface, a server, a shared gateway, a management endpoint, a customer assignment or unused space. Carrier-grade network address translation can place many subscribers behind a smaller public pool. A hosting environment can place many applications behind one address. Private address space can support a large internal or access network without appearing in the origin count.

The 1,024-address figure therefore cannot be multiplied into an estimate of households or businesses. It does not reveal whether assignments are static, dynamic or shared. It does not show what fraction is active or reserved. It cannot distinguish consumer access, enterprise service, hosting, network management or other uses.

Address count also says nothing about capacity. A /24 can travel over a low-capacity link or a high-capacity interconnection. The route table does not expose port speed, optical channels, radio spectrum, transit commits, traffic volume, contention or oversubscription. Four prefixes do not imply four times the bandwidth of one prefix.

The appropriate use of the count is operational monitoring. It defines the complete visible IPv4 set in the snapshot and makes partial changes easy to detect. One missing /24 would remove one quarter of the public allocation from the observed origin set. That would be a meaningful routing event, but its customer impact would still depend on address use and network design that remain private.

The sampled RPKI result is strong and deliberately narrow

The bounded RIPEstat RPKI query for 102.203.196.0/24 and origin AS329678 returns valid. Its validating entries include an exact /24 Route Origin Authorisation with a maximum length of 24. The response also lists covering /23 and /22 entries as invalid_length for this /24 query because those covering authorisations do not permit a /24 under their respective maximum lengths.

The endpoint's overall result is the key field: the exact /24 has a validating route-origin authorisation for AS329678 in the captured Routinator view. That gives relying networks a positive origin-validation signal for this route, subject to their own policy and validator freshness. It is stronger metadata than an unknown result.

The query covered one prefix. It does not prove that 102.203.197.0/24, 102.203.198.0/24 or 102.203.199.0/24 have the same status. The address allocation and origin ASN are shared, but RPKI validation is evaluated against the exact announced prefix and maximum length. A responsible account must not promote one sampled result into a claim about all four routes.

Even a valid result has a limited scope. RPKI helps determine whether the origin ASN is authorised for the prefix. It does not validate the full AS path, prove that the operator's routers are secure, guarantee reachability, prevent congestion or certify the physical network. A valid ROA can coexist with an outage, a route leak elsewhere in the path or a common physical failure.

The sample is valuable because it adds a security-metadata checkpoint to the public baseline. Future monitoring can validate every announced /24 and record changes. Until then, the accurate statement is that the first /24 sampled valid for origin AS329678, while the other three remain outside the evidence.

No visible IPv6 origin leaves a defined question

RIPEstat reports zero originated IPv6 prefixes and zero IPv6 /48 equivalents for AS329678. Its visibility field shows zero of 324 full-table IPv6 RIS peers seeing an announcement from the ASN. The public origin surface in the captured snapshot is therefore IPv4-only.

That observation should not be rewritten as "the company has no IPv6." An operator can use IPv6 internally, provide it through another autonomous system, test it privately or prepare a deployment that is not yet globally visible. Customers can obtain IPv6 through wholesale arrangements not represented by the AS329678 origin set.

The absence remains relevant because a public IPv6 origin is one independently measurable sign of external deployment. It shows that address allocation, routing policy and upstream acceptance have reached the running Internet. Without such an origin, an outside observer cannot verify those layers for this ASN.

The correct due-diligence question is therefore specific. Is IPv6 unavailable, delivered through another origin, in testing or planned? If it is provided through a different ASN, what operating relationship connects that service to High Speed Access Company? If it is planned, what prefix and validation policy will define the public boundary?

A future IPv6 announcement would be a material change in the company's visible network identity. It could be compared with the present IPv4-only baseline without treating the current zero as a judgement on technical skill. The public record supports monitoring, not a capability verdict.

The access network behind the routes remains unverified

The company name contains the phrase High Speed Access, and the directory classifies it as a regional ISP. Neither label maps the physical access network. The source set does not show streets, neighbourhoods, towers, cabinets, fibre routes, wireless sectors, buildings or customer premises. It does not identify a service footprint within Libya.

Global routing evidence lives at the network edge. It shows how public address space is originated and which adjacent autonomous systems appear in paths. Customer access may depend on owned plant, leased circuits, wholesale networks, wireless links or a mixture of them. BGP does not distinguish those arrangements.

This limitation is not a defect in the routing sources. It is a boundary between layers. AFRINIC and RIPEstat are well suited to number-resource identity, origin, visibility and path observation. They are not asset registries, construction records or service-availability maps. Asking them to prove poles, towers or fibre would turn reliable evidence into speculation.

The hidden access layer contains many of the risks that matter most to users. A cut can isolate a neighbourhood while all four public routes remain visible. A power failure can stop local aggregation without withdrawing the origin immediately. A wireless backhaul fault can affect customers even when the Internet-facing sessions are healthy. Field access, spare parts and repair labour can dominate recovery time.

None of those events is documented for High Speed Access Company in the current evidence. They should not be asserted as known weaknesses. They are unanswered dependencies that the public routing baseline helps frame. The routes prove that an external boundary exists. They do not reveal how customers reach it.

Physical diversity cannot be read from two AS numbers

The presence of AS21003 and AS37284 in observed paths may look like upstream diversity. At the routing-policy layer, two relationships can offer options. If one path disappears and the other remains available, BGP may select an alternate route. Whether that preserves service depends on configuration, capacity and the physical fault domain.

Two sessions can share one router. Two carriers can lease the same fibre segment. Separate handoffs can enter one building through a common duct. Both networks can depend on the same power or regional transport system. A logical failover can succeed while the alternate path lacks capacity for normal load. None of those conditions appears in the public path data.

The opposite is possible too. One observed neighbour can deliver multiple physically diverse circuits, and additional backup relationships can remain invisible in the current sample. This is why neither the count two nor the absence of a third neighbour should be treated as a definitive topology diagram.

Operational continuity requires more detailed evidence: handoff locations, transport ownership, route policy, tested failover behaviour, capacity under failure, power domains, configuration recovery and escalation procedures. Some of that information can remain confidential while an operator still provides a credible summary to customers and partners.

The public record sets a reasonable minimum question. High Speed Access Company has four visible prefixes and two observed routing counterparts. Which common physical dependencies could remove both relationships or all four routes at once? The answer cannot be inferred, but the question follows directly from the boundary that is visible.

Service quality sits below the route table

Nothing in the eight-source set measures latency, packet loss, throughput, availability, repair time or support responsiveness. The 328-of-329 visibility result may coexist with excellent service, poor service or mixed performance across different customers. BGP propagation and customer experience are connected but not interchangeable.

A prefix can remain visible while local congestion degrades traffic. DNS can fail while the route is stable. A router can advertise addresses for servers or access systems that are unavailable. Conversely, a brief route withdrawal may have little user impact if sessions recover quickly or traffic uses another mechanism. The route table records reachability information, not an end-to-end service-level agreement.

Capacity is similarly absent. No source states port speeds, backhaul capacity, transit commits, radio spectrum, fibre pairs or oversubscription. The current address and neighbour counts cannot fill that gap. A small address portfolio can sit on substantial transport, and a larger portfolio can be constrained by modest links.

Public monitoring can still identify events that deserve investigation. A missing /24, changed origin, lower visibility or altered neighbour set would show a routing-layer change. The event could then be compared with customer reports and operator statements. The routing data would narrow the timeline without determining the cause.

This discipline protects readers from two errors. It prevents broad route visibility from becoming marketing proof of quality, and it prevents missing performance data from becoming an allegation of poor service. The source set establishes a real network identity and a measurable operating surface. It leaves service quality open.

A four-route footprint creates a precise failure ledger

Because AS329678 currently exposes four /24s, future changes can be classified more precisely than a simple "up" or "down" label. If one /24 disappears, the public origin set loses one quarter of the allocated address space while the rest may remain. If all four disappear together, a common routing or physical dependency becomes a plausible question, though not a proven cause.

An origin change would create a different event. A prefix appearing under another ASN could reflect an authorised migration, a customer arrangement, a configuration error or an unauthorised announcement. The present baseline records AS329678 as origin, allowing a later observer to identify the exact field that changed without deciding the explanation in advance.

Neighbour changes form a third category. One of the two observed counterparties may vanish from paths, or another may appear. Collector visibility, policy and traffic engineering can alter that view even when contracts remain unchanged. The event should be recorded before it is interpreted.

RPKI status adds another independent field. The sampled /24 is valid now. A change to invalid or unknown would alter the origin-validation surface without necessarily changing BGP reachability. The other three /24s require their own baseline before they can be monitored on equal terms.

This layered failure ledger is more informative than generic claims about network health. Prefix set, origin, visibility, neighbours, registered allocation, policy consistency and RPKI status describe connected but distinct surfaces. Recording the exact surface that changed makes later operational analysis more credible.

Registry contactability is part of continuity, not proof of it

AFRINIC's RDAP records associate administrative and technical entity handles with the ASN and IPv4 allocation. Those roles make it possible for other networks and registry users to identify responsibility for the resources. Accurate contact structures matter when routing incidents, abuse reports or allocation questions require coordination.

The existence of contacts does not show whether messages reach the right person, whether escalation works outside business hours or whether an incident receives a timely response. A registry can be current while the operational process behind it is weak. A public entity can look stale while experienced staff remain reachable through other channels. Response quality needs direct evidence.

The shared organisation handle across the ASN and IPv4 entities reduces one kind of ambiguity. An operator investigating 102.203.196.0/24 can connect the address range to AS329678 without reconciling unrelated registrants. That clarity can shorten the first stage of incident handling.

Continuity also depends on control of credentials and operating knowledge. Maintainer access, router configurations, RPKI keys, DNS, monitoring and vendor escalation all need ownership and recovery procedures. None of those controls is disclosed in the source set. The registry makes responsibility visible but cannot certify the resilience of the responsible organisation.

Treating contactability as a separate layer gives it the right weight. It is more than clerical detail because number resources require accountable maintenance. It is less than a service guarantee because records only become useful when people and systems act on them.

The most useful diligence questions are narrow

A customer or counterparty can begin with the allocation itself. Are the four /24s the complete public origin set for AS329678? What operating functions use each block? Are addresses assigned to access customers, infrastructure, hosted services or a mixture? What controls govern a partial route withdrawal?

The two observed neighbours support another set of questions. What commercial relationships do AS21003 and AS37284 represent? Where do the handoffs terminate? Do they share transport, facilities, power or equipment? Can either path carry normal demand during a failure, and when was that condition last tested?

Physical access needs separate evidence. Which parts of the network are owned, leased or wholesaled? What dependencies connect customer premises to the public routing edge? Which components are single points of failure? What repair resources, spare equipment and escalation paths apply when an access segment fails?

IPv6 and RPKI questions should remain exact. Is IPv6 delivered through another origin or not publicly deployed? What is the validation state of the other three /24s? Are route-origin authorisations monitored when prefix length or origin policy changes?

These questions do not require publication of sensitive topology or contract terms. An operator can provide scoped evidence, describe tested boundaries and distinguish confidential details from undisclosed controls. The public data has already done its most useful work by showing where the questions attach.

A disciplined change log would improve accountability

AS329678 is well suited to periodic monitoring because the current surface is compact. A snapshot can record four prefixes, origin ASN, peer visibility, two observed neighbours, the registered covering allocation, IPv6 state and per-prefix RPKI status. Each field can be compared without estimating private operations.

A useful change log should preserve dates and sources. Registry updates, route changes and RPKI changes happen on different clocks. Combining them into one undated profile would obscure whether an apparent conflict reflects stale data or a genuine operating transition.

The log should also avoid causal claims. A withdrawal can be recorded without calling it an outage. A new neighbour can be noted without claiming a new contract. A valid ROA can be recognised without calling the route secure. Precision about the observed field makes later explanations easier to test.

For the operator, accurate public records can reduce friction during supplier checks, abuse handling and routing incidents. For customers, they create a baseline that is independent of marketing language. For researchers, they make it harder to confuse allocated resources with commissioned service.

Accountability does not require exposing every private design detail. It requires maintaining the uniqueness and accuracy of the number-resource record, observing the running route, and naming the boundary where evidence ends. AS329678 already supplies enough public structure for that discipline.

The public surface is a reality layer, not an endorsement

High Speed Access Company's routing identity has several positive, verifiable features. The ASN and IPv4 allocation share an AFRINIC organisation handle. Four /24s are present in both registry and BGP data. The origin is broadly visible to RIPE RIS. One sampled /24 has a valid RPKI result. Two adjacent ASNs define an observable external handoff surface.

The limitations are just as concrete. Registered policy does not document the observed neighbour pair in the endpoint used here. No IPv6 origin appears. Three of the four /24s lack RPKI evidence in this source set. Physical access, capacity, customers, coverage, performance, ownership and resilience remain undisclosed.

Holding both sets of facts together is more useful than advocacy. The company should receive credit for the public number-resource and routing surface that can be verified. That surface should not be inflated into claims about assets or service quality. Missing evidence should become a bounded question, not a negative verdict.

This approach treats the registry as a ledger rather than a sovereign guarantee. It gives running routes priority over static description while recognising that BGP cannot expose every dependency. It treats security metadata and operational continuity as measurable concerns without pretending that one valid ROA proves a safe or resilient network.

The result is a durable public baseline. It constrains what can honestly be said today and identifies which changes would matter tomorrow.

Route announcement is not the same as commercial commissioning

Infrastructure descriptions often compress several milestones into the word "live." AS329678 shows why that shortcut is unsafe. AFRINIC can assign a number resource before the operator announces it. A route can appear in BGP before a customer-facing access system is commercially available. Equipment can be installed without power, powered without carrying production traffic, and technically reachable without being sold as a supported service.

The current evidence establishes two milestones. The resources were recorded in December 2025, and RIPE RIS observed an origin beginning in January 2026. By July, four /24s were broadly visible. The evidence does not establish when access equipment was installed, when circuits were energised, when an end-to-end service was commissioned, or when customers could order it under commercial terms.

This distinction affects capacity claims. A route can advertise all 1,024 addresses while only part of the physical access network is built. Installed switching or radio capacity can exceed the capacity that is powered, lit, provisioned, sold or usable during a fault. Conversely, a provider can serve many users through shared addressing while announcing a small public pool. Neither the prefix count nor the allocation size resolves those stages.

Ownership requires the same care. AS329678 may control routing policy while depending on leased transport, wholesale access, shared facilities or equipment operated by another party. The public number-resource identity says who the registry associates with the resource. It does not say who owns each physical dependency or which party must restore it after failure.

A credible commissioning account would therefore need evidence from below BGP: dates for installation and energisation, acceptance or test records, customer-availability terms, and a clear operator boundary. It would also need to distinguish design capacity from installed capacity, installed capacity from lit capacity, and lit capacity from the capacity that can actually be carried during a failure.

Until such evidence exists, the route should be called announced and observed, not commissioned access infrastructure. That wording does not minimise the operational reality of BGP. It prevents one layer's completion from being mistaken for completion of every layer beneath it.

Conclusion

High Speed Access Company for Telecommunication and Technology has a clear public routing identity in AS329678. AFRINIC assigns the ASN and the contiguous range 102.203.196.0-102.203.199.255 to the same organisation handle. RIPEstat sees the 1,024-address allocation originated as four /24s rather than one /22 aggregate.

At the captured 28 July 2026 snapshot, the routes reached 328 of 329 full-table IPv4 RIS peers. AS21003 and AS37284 appeared as the two observed neighbours. That is strong evidence of a live external routing surface. It is not proof of two physically independent upstream paths or a resilient customer network.

The registered and running layers align for the four /24s but not for every field. The covering /22 exists in AFRINIC data without appearing as the observed aggregate route. The two neighbours appear in BGP without corresponding public import or export policy in the consistency response. One sampled /24 validates in RPKI; the other three remain outside the bounded check.

No IPv6 origin appears. More importantly, none of the sources reveals access plant, facilities, customers, capacity, service area, performance, power, repair practice or common failure domains. Those unknowns are not evidence of failure. They are the operational boundary behind the route table.

The central finding is therefore the difference between recorded control and delivered service. AFRINIC preserves the unique number-resource identity. RIPE RIS shows the four routes in operation. Together they create a reality layer for monitoring origin, visibility, neighbours and validation. They leave the physical and organisational continuity of the access service open to evidence rather than assumption.

AS329678 turns one Libyan IPv4 allocation into four public routes, while the access network stays opaque