Summary
- At 08:00 UTC on 16 July 2026, RIPE RIS observed AS135632 originating
103.77.9.0/24,116.206.164.0/24and116.206.167.0/24: 768 IPv4 addresses in three routes, with no originated IPv6. Every one of the 1,063 collected AS paths placed AS141421, MUX Broadband, immediately before Cactus. - The evidence establishes one visible neighbouring autonomous system, not one physical cable. It does not disclose how many BGP sessions, handoffs, circuits, routers, buildings, rooftop relays, ducts or power domains sit beneath that logical relationship.
- The route estate has changed materially. RIPE saw eight IPv4 prefixes and one neighbour in July 2025, no Cactus-originated routes in a mid-October snapshot, seven prefixes through AS141421 by April 2026, and three by May. Those observations prove routing changes, not customer loss, physical migration or reduced installed capacity.
- Cactus's website and mail are hosted in AS31898 rather than AS135632, so those public contact surfaces could remain reachable during a withdrawal of Cactus-originated routes. Customer access, local services, internal switching and support operations would depend on arrangements that are not visible in public routing or company material.
The session stops at 08:00 UTC
Begin with the failure rather than the brochure.
At 08:00 UTC, the edge session carrying Cactus Network Solutions' three public prefixes to AS141421 stops exchanging usable reachability. The cause could be a failed interface, an upstream maintenance error, a router restart, a damaged access circuit, a configuration mistake or lost power at either end. Once any route-retention interval expires, and provided no second session or neighbour begins advertising the same prefixes, the effect outside the network is simple: other autonomous systems stop learning how to reach 103.77.9.0/24, 116.206.164.0/24 and 116.206.167.0/24.
That is not a hypothetical topology invented from a company name. The publication-date RIPEstat routing-status snapshot counted three originated IPv4 routes, 768 addresses, no IPv6 routes and one observed neighbour. The corresponding BGP-state capture contained 1,063 collector paths. AS135632 was the origin in all of them, and AS141421 was the immediately preceding autonomous system in all of them.
What remains reachable in the failure moment is more revealing than what disappears.
Cactus's public domain resolved to 192.185.56.104 in the A response returned by Google Public DNS. RIPE's network-information response for that address placed its covering route in AS31898, outside AS135632. The domain's mail exchanger was mail.cactuspk.com, which resolved to the same externally hosted IPv4 address. Its authoritative name servers also used the websitewelcome.com namespace. Therefore, withdrawal of Cactus's own routes would not, by itself, withdraw the public website's hosting prefix or the mail host's prefix.
The website might still load. An email server might still accept mail. A caller might still reach the published telephone number over a separate telecommunications service. None of those outcomes proves that a Cactus subscriber can reach the wider internet. Staff inside a Cactus-served office might be unable to reach the externally hosted support systems even while those systems remain available to everyone else. A customer and a support engineer could thus see opposite sides of the same failure: the support page is online from abroad, while the customer circuit has no usable route out.
Local communication is a separate unknown. If customer access radios, switches, addressing and local services remain powered, packets between two points inside the same routing domain might continue to move without a global route. They might also depend on central systems or paths that fail with the upstream handoff. Public evidence does not show the internal topology, whether subscribers use public or private addressing, where authentication occurs, or whether local traffic is switched locally. The correct answer to “what remains reachable?” is consequently a list to be measured, not a confident assumption.
What the public routing table establishes
BGP is an inter-domain reachability protocol. The base BGP specification describes the exchange of prefixes and AS-path information between routing systems. It does not encode a street route, fibre drawing, rooftop location, power feed, port speed or repair contract. The Cactus evidence has to be kept in those layers.
| Evidence word | What it means here | What it does not mean |
|---|---|---|
| Registered | A public registry record associates an organisation, contact or number resource with Cactus. | The resource is currently routed, occupied, physically in Lahore or carrying customers. |
| Announced | AS135632 originated a prefix into BGP during a stated interval. | Every address was active, capacity was available, or every customer could pass traffic. |
| Observed | RIPE collectors received a route or AS path at a stated time. | Every network in the world saw the same path, or the path maps to one physical circuit. |
| Unknown | Public material did not establish the fact. | The asset or safeguard is absent, defective or unused. |
At the publication cut-off, RIPE's announced-prefixes result for 1-16 July showed the same three /24s continuously from the beginning of the requested interval through the latest available observation at 08:00 UTC on 16 July. The routing-status result said 320 of 326 IPv4 RIS peers saw the routes. No IPv6 prefix was visible to any of the 321 IPv6 peers in that snapshot.
The per-prefix path evidence is unusually consistent. RIPE returned 360 paths for 103.77.9.0/24, 360 for 116.206.164.0/24 and 343 for 116.206.167.0/24. Every captured path for each prefix ended AS141421 AS135632. There was no collected path in which another autonomous system appeared directly before Cactus.
That finding is stronger than saying a commercial directory lists one provider. It is a route-by-route observation across hundreds of collector views. Yet its limit is equally important. Several physical links or several BGP sessions can exist between the same two autonomous systems while producing the same AS path. Conversely, one BGP session can be carried over infrastructure with hidden protection inside a supplier's network. The AS path alone cannot distinguish those cases.
The operator-maintained PeeringDB profile for AS135632 identifies Cactus, also using the Sprint Broadband name, as a Pakistan Cable/DSL/ISP network. It does not publish exchange or facility rows. That absence narrows what can be verified through PeeringDB; it does not prove Cactus has no equipment in a shared facility, no private interconnection, no remote exchange access and no protected wholesale service.
APNIC's public organisation record for ORG-CNSP1-AP identifies Cactus Network Solutions (CNS) Pvt Ltd as a Pakistan local internet registry and gives a New Garden Town, Lahore address. The maintainer record and incident-response contact record preserve the same organisational identity and current contact maintenance. These are good evidence that the company remains an active resource holder. An administrative address is not evidence of a core router, relay, warehouse, customer aggregation point or upstream handoff at that building.
Three /24s are neither capacity nor customer count
A /24 contains 256 IPv4 addresses. Three /24s therefore contain 768 addresses. This arithmetic is exact and operationally limited.
The number does not reveal subscribers. One household could receive a public address, many households could share one through carrier-grade translation, a business could receive several, and infrastructure interfaces could consume part of the pool. Addresses can also be reserved, routed but idle, used for network equipment or assigned dynamically. No public source establishes Cactus's current addressing policy.
Nor does the address count reveal bandwidth. A 100 Mbps transit commit and a 10 Gbps transit commit can originate the same three prefixes. The routes say where packets should go; they do not state how much traffic the handoff can carry before congestion, which classes are prioritised, what burst terms apply, or how much spare capacity exists after a failure.
Each /24 has its own history but the same current exit
The three current routes should not be treated as one indivisible statistic. Each is independently advertised, can be independently withdrawn, and can carry a different mix of infrastructure or subscriber addresses. Public data does not reveal that mix, but it does make the routing behaviour of each /24 separately observable.
| Current route | Paths captured at 08:00 UTC | Recent observed continuity | Current immediate neighbour | Origin-validation result |
|---|---|---|---|---|
103.77.9.0/24 |
360 | Visible throughout 1-16 July; absent from 16 April until 12 May before returning | AS141421 | Unknown |
116.206.164.0/24 |
360 | Visible throughout 1-16 July; continuously visible from 8 January through the publication cut-off after short early-January gaps | AS141421 | Unknown |
116.206.167.0/24 |
343 | Visible throughout 1-16 July; continuously visible from 1 November 2025 through the publication cut-off | AS141421 | Unknown |
The lower path count for 116.206.167.0/24 is not evidence of lower bandwidth or worse customer service. It means fewer collector paths were present in that captured response. Collector participation, filtering and timing can differ. What is common across the three results is more important: every captured path used AS141421 at the final external-AS boundary.
There was also no observed covering route to absorb the loss of a more-specific announcement. RIPE returned no BGP state for the covering 103.77.8.0/22 or 116.206.164.0/22 at the same timestamp. Thus, in the captured public table, withdrawal of 103.77.9.0/24 would not leave a Cactus-originated /22 route covering it. The same is true for the two visible 116.206 /24s.
That detail gives Cactus two different resilience problems.
The first is shared failure. If the AS135632-AS141421 boundary stops carrying all exports, all three routes can disappear together because they share the same visible neighbour. The second is selective failure. A route filter, prefix-specific policy error or local origination problem can remove one /24 while the other two remain healthy. Customers in the affected range could be unreachable even while an aggregate dashboard says AS135632 is still online.
This is why an external monitor should test at least one controlled address in every originated prefix. A single probe to the company website would be useless because the site is outside the Cactus ASN. A single probe inside 116.206.167.0/24 would miss a selective withdrawal of 103.77.9.0/24. Reachability should be tested from several independent networks, with the result tied to the BGP state at the same time. That would distinguish at least three events: route absent, route present but endpoint unavailable, and endpoint reachable with degraded packet delivery.
The route history also gives the operator a natural test case. 103.77.9.0/24 returned after nearly four weeks of absence in April and May 2026, while 116.206.164.0/24 and 116.206.167.0/24 were visible on both sides of that interval. Public data cannot say whether the returning route carried subscribers, infrastructure or unused space. Cactus can. It could use the event to explain whether the withdrawal was planned, how address users were handled, what alarms fired and why the route returned.
The four /24s no longer visible after 16 April deserve the same disciplined wording. 103.77.10.0/24, 103.77.11.0/24, 116.206.165.0/24 and 116.206.166.0/24 appeared in RIPE's history and were absent at publication. That is an announcement fact. It is not evidence that the corresponding registered address space was sold, abandoned, revoked or physically disconnected. A current prefix inventory should label each block as routed, reserved, used internally, assigned through another arrangement or retired, with the date and authority for the state.
For a buyer, this is not clerical detail. If a promised static address sits in a /24 that is sometimes withdrawn independently, the service-level question is route-specific. If critical equipment is spread across two of the current /24s, that may protect against a prefix-specific error but not against the common AS141421 boundary. If all customer translation pools, DNS resolvers and management systems sit in one /24, the other two routes may offer less practical separation than the route count suggests. The public table cannot reveal those placements.
The three-route footprint is therefore small enough to audit precisely. Cactus can publish a non-sensitive inventory, monitor every prefix, test normal and alternate exports, and preserve an event record when any route changes. That would be more informative than a broad uptime percentage because it would show exactly which address population remained reachable under which failure.
The company homepage makes much larger-looking claims, including gigabit service, an all-IP wireless network, institutional leased lines and more than 20,000 trusted users. But the live Cactus homepage also contains sales text about broadband plans in India, theme-vendor testimonials and generic language unrelated to the Lahore operator. The contact page includes an Aivahthemes popularity claim alongside the Lahore address. A separate contacts page has sample Chicago and New York details. Those residues make the site's numerical scale claims unsuitable as operating facts.
The safer conclusion is smaller. The site is reachable, presents Cactus as a residential and business internet provider, publishes Lahore contact details, and discusses wireless, fibre and leased-line services. It does not provide a reliable current subscriber total, orderable coverage map, active tower inventory, transit capacity, utilisation series or audited uptime record. The 768-address route footprint should not be inflated with numbers from compromised sales copy.
An independent IPinfo page for AS135632 corroborates the current three-prefix, 768-address and zero-IPv6 view and labels the network as a consumer ISP. It also reports a small set of ping-responsive Cactus addresses. Those probes support the proposition that endpoints in the routes answer from Pakistan; they do not identify customers, active service areas, radio sites, congestion or resilience. An independent bgp.tools profile still lists seven IPv4 prefixes and the same upstream ASN. Its larger count reflects a broader or differently timed inventory than the publication-date RIPE view. The difference is a reason to time-stamp claims, not to select the larger number.
The route estate has already changed
The most useful evidence about failover is not a promise. It is what the routes have done.
On 16 July 2025, RIPE observed AS135632 originating eight IPv4 prefixes, covering 2,048 addresses, with no IPv6 and one neighbour. The neighbour visible that day was AS24499, Telenor Pakistan, as shown by the historical neighbours response. This is evidence of a different public upstream boundary from the one seen in July 2026.
The one-year announcement history then records a sharp break. The prefixes visible in the summer of 2025 ended on 26 September. RIPE's update stream for 103.77.9.0/24 shows widespread withdrawals after paths through AS24499. No AS135632-originated prefix appears in the mid-October routing-status snapshot.
On 22 October, announcements returned. The update stream around the restoration shows new paths ending AS141421 AS135632. By 15 April 2026, seven IPv4 /24s were visible through one observed neighbour, AS141421. Four of those seven stopped appearing on 16 April. 103.77.9.0/24 also disappeared and returned on 12 May. The 13 May snapshot had settled on the present total of three.
These timestamps establish three things.
First, AS135632 has changed its visible upstream boundary. Second, its public route set has contracted from eight to seven to three across the observed period. Third, there was an interval of roughly 26 days between the September withdrawal and the October restoration during which RIPE did not see an AS135632 announcement.
They do not establish why. A collector-visible absence could coincide with a provider migration, a deliberate routing change, use of provider-assigned addresses, a policy error, suspended service or another condition. It does not tell us whether retail customers were offline, moved behind different public space, served through another ASN, using private connectivity, or not yet active. Likewise, the withdrawal of four /24s in April 2026 does not prove that Cactus lost customers or decommissioned equipment. Those addresses might be unused, held, routed differently or awaiting another purpose.
The history nevertheless matters to a buyer. It proves that the public configuration is not static and that a neighbour change has occurred. A credible resilience explanation should therefore answer not only “who is upstream today?” but also “how did traffic continue during the last upstream transition, which prefixes moved, how long did convergence take, and what did customers experience?”
One neighbour can conceal several circuits, but not a second AS path
AS141421 is identified by APNIC's autonomous-system record as MUX Broadband (Private) Limited in Pakistan. At the same publication-time cut, MUX's RIPE routing status showed five originated IPv4 prefixes, three IPv6 prefixes and seven observed neighbours. Its neighbour view included three autonomous systems appearing before MUX on observed paths and four appearing after it, one of them AS135632.
MUX's broader connectivity may make the service it sells more resilient than a single external link. That resilience cannot be transferred automatically to Cactus. The failure boundary in question is the boundary between AS135632 and AS141421. If MUX retains excellent routes to the wider internet but Cactus cannot deliver its prefixes to MUX, those upstream options do not help the Cactus addresses. The same applies if a shared Cactus edge router, local handoff, power supply or configuration fails before traffic reaches MUX.
At the same time, the one-neighbour result does not justify drawing one line on a city map. Cactus could have two circuits to MUX at different locations, two routers on one circuit, two sessions over one protected service, or one unprotected handoff. MUX could carry traffic over redundant infrastructure internally. None of those designs is visible in the AS path. The exact physical route between the companies, including whether it crosses Lahore, Multan or any named facility, is unknown.
An official Punjab healthcare procurement evaluation creates a useful tension. The 19 July 2023 technical bid report marked Cactus “Yes” against a requirement that a bidder have two upstream providers, written as PIE and TW1. The same table marked it compliant for LL/CVAS licensing and ultimately responsive.
That document is strong evidence of what the procurement evaluators accepted in 2023. It is not a current BGP diagram. It does not identify the circuits, ASNs, sites, route advertisements, contract periods or failover behaviour behind the two-upstream response. The requirement may have concerned a particular managed service, wholesale suppliers behind another provider, then-current commercial capacity or evidence not reproduced in the two-page evaluation. The present RIPE view, by contrast, answers a narrower question: which autonomous system appeared directly before AS135632 in public paths on 16 July 2026? The answer was only AS141421.
The procurement “Yes” and the routing snapshot are therefore not mutually exclusive. Together, they define the due-diligence question. Cactus can resolve it by identifying the two current failure domains, showing which public prefixes each carries, and demonstrating that a controlled loss of one causes the other to announce and forward usable routes within a stated interval.
IPv6 is missing, but it would not be a magic backup
The current Cactus route estate has no visible second address family. RIPE counted zero originated IPv6 prefixes in July 2025, April 2026, May 2026 and the publication-date snapshot. IPinfo and bgp.tools independently report the same absence. Cactus's public domain also returned no address in the Google Public DNS AAAA response.
IPv6 is a distinct network-layer protocol, specified in RFC 8200, with a much larger address space than IPv4. In a properly engineered dual-stack service, a customer and application can have both IPv4 and IPv6 reachability. Client techniques described by Happy Eyeballs Version 2 can try the available families in a way intended to reduce user-visible delay when one path is poor.
But IPv6 is not an automatic substitute for a failed IPv4 route. The customer device must receive working IPv6 configuration. The access network must carry it. DNS must publish an IPv6 destination where appropriate. The destination must be available over IPv6. Cactus must advertise an IPv6 prefix, and the upstream relationship must carry it. None of that public route evidence exists for AS135632 at the cut-off.
Even if Cactus added IPv6 tomorrow, address-family diversity would not necessarily create physical diversity. IPv4 and IPv6 can traverse the same router, the same radio, the same fibre, the same handoff and the same upstream ASN. A power loss or cut at that common point would remove both. Conversely, IPv6 delivered over an independently powered and routed path could preserve some dual-stack applications during an IPv4-specific routing failure. The benefit depends on implementation, not on the presence of an IPv6 allocation alone.
MUX's own route status proves that the visible neighbour is capable of originating IPv6. It does not prove that MUX offers Cactus an IPv6 service, that Cactus has requested one, or that customer equipment is ready. The publication-time absence is therefore specific: no Cactus-originated IPv6 route was visible. The reason, deployment plan and customer effect are unknown.
This matters economically as well as technically. A small IPv4 pool can encourage address sharing, complicating inbound services, abuse handling and customer attribution. IPv6 can reduce address scarcity and improve end-to-end reachability for compatible services. Yet deployment requires customer-premises support, monitoring, security policy, staff practice and help-desk readiness. For a regional provider, the test is not “does the upstream support IPv6?” but “can a customer use it, can operations diagnose it, and does it survive a defined failure?”
The last mile is suggested, not mapped
Cactus presents itself as a local access provider rather than a pure routing shell. Its services page separates residential, business and custom connectivity. The business-services page discusses dedicated broadband, network management and secure connectivity. The homepage refers to an all-IP wireless network and asks users to check for towers in their locality.
Those descriptions support a broad inference that Cactus has marketed last-mile and enterprise access, including wireless delivery. They do not establish a current tower count, fibre route, pole estate, licensed spectrum holding, customer-premises inventory or service boundary. The site's stock-theme residue makes its percentages, subscriber totals and broad coverage language especially weak.
A more concrete but historical document is a Cactus proposal dated 25 September 2020, publicly uploaded to Scribd. It proposed a 20 Mbps committed-information-rate point-to-point link in Lahore using two 34 dBi dishes and two 5 GHz AirFiber units. It allowed two days for installation, included recurring link and tower maintenance, referred to frequency registration, and assigned proper power and earthing at the customer site to the customer.
The proposal is useful because it describes an actual commercial design under the Cactus name. It is limited because it is six years old, specific to one proposed circuit, hosted by a third party and not proof that the link was ordered, installed or remains active. It cannot be extrapolated into a current map of Cactus towers. It does, however, identify failure surfaces that remain technically plausible for fixed wireless: line of sight, antenna alignment, rooftop access, radio health, interference, customer-site power, grounding and the availability of replacement equipment.
No reviewed source supplies coordinates for an operating Cactus relay or tower. The Garden Town addresses in the company and APNIC records are administrative contact locations. The Al-Qadir address in the 2020 proposal is a historical office address. None should be plotted as a network node without separate evidence.
Fibre is similarly unresolved. The live site uses fibre language, and a supplier can deliver fibre access without owning every cable, duct or pole. Public material does not identify whether Cactus owns access fibre, leases tails, resells another carrier, combines wireless and fibre, or hands customers to third-party infrastructure. A BGP path through MUX cannot answer that question. The logical adjacency could sit above any of those physical arrangements.
Power and field repair decide whether a route is usable
Routing diversity is valuable only if the equipment that uses it remains powered and repairable.
Consider four failures. If a rooftop radio loses power but the Cactus edge continues announcing all three prefixes, the global routing table can look healthy while customers behind that relay are offline. If the edge session to MUX fails while the access network remains powered, local links may stay up but external destinations may disappear. If both nominal and alternate circuits enter the same building and one local power event disables the shared router, two contracts produce no usable diversity. If a storm moves a point-to-point antenna, spare upstream capacity does not restore line of sight.
The 2020 wireless proposal explicitly made customer-site power and earthing a commissioning condition and excluded damage caused by surges, fluctuations or inadequate grounding. That contractual boundary is operationally important. It suggests at least one historical Cactus design in which service availability depended partly on customer-controlled electrical conditions. It does not reveal whether Cactus supplied uninterruptible power, batteries or surge protection elsewhere, or what runtime any backup system had.
A separate support-services agreement dated December 2020, also publicly uploaded, described remote diagnosis first and an on-site visit if remote work failed. It listed a support number, several technical contacts and a management escalation sequence. This is evidence that Cactus documented a field-escalation practice for one client at that time. It is not a current staffing roster, a network fault commitment or proof that the same people, hours and response times cover broadband customers in 2026.
The current Cactus contact page lists an Awami Complex address in Garden Town, a telephone number, email and office hours of 9 a.m. to 5 p.m. The site elsewhere claims extensive or round-the-clock support. Because the same pages contain unrelated stock content, the exact support promise requires confirmation in a current customer contract.
For a small operator, local labour can be the effective reserve. A spare radio in a cupboard is useful only if someone can identify the failed unit, obtain rooftop access, travel through Lahore, align the replacement safely and close the fault. A second transit session is useful only if someone monitors it, maintains policy parity and notices when it has silently stopped accepting a prefix. The number of technicians is less important than the tested coverage of skills, shifts, access permissions and spares.
None of those quantities is public for Cactus. There is no current mean-time-to-repair series, on-call schedule, spare inventory, rooftop-access plan, battery runtime, generator policy, fuel reserve, maintenance window, monitoring coverage or post-incident account. Their absence from public material is not proof of weak operations. It means a customer cannot price resilience from the website and BGP table alone.
Route-origin security is a different test
All three current prefixes returned an unknown result from RIPE's route-origin validation service: 103.77.9.0/24, 116.206.164.0/24 and 116.206.167.0/24. No validating route-origin authorisations were returned.
Origin validation, described in RFC 6811, allows a router to compare an announced prefix and origin ASN with cryptographically verifiable authorisation data. An unknown state is not an invalid route. It means the validation system did not find a covering authorisation that made the announcement valid or invalid.
Publishing correct authorisations could reduce one class of routing risk: another network accidentally or maliciously originating Cactus space. It would not create a second upstream, add bandwidth, power a radio or shorten a repair journey. Availability and route-origin security should therefore be measured separately. A resilient network can still have weak origin protection, and a perfectly authorised route can still vanish when its only usable handoff fails.
A testable resilience claim has five parts
Cactus does not need to reveal sensitive diagrams to make its resilience assessable. It needs to publish or provide verifiable answers at the boundaries where failures propagate.
1. Export the same routes over a genuinely usable alternate
For each of the three current /24s, identify the normal and alternate external routing arrangements. If both sessions are with AS141421, state whether they terminate on different Cactus routers, different MUX devices, different handoff sites and physically independent access circuits. If a second autonomous system exists, show that each prefix is accepted and propagated through it.
Then perform a controlled withdrawal of the normal session. Measure the time until external probes regain stable reachability through the alternate. Test all three routes, not one representative address. Record whether stateful customer sessions survive, whether translation pools change, and whether return paths remain usable.
The 2023 procurement response about two upstreams makes this test especially reasonable. A buyer should ask for current evidence rather than assume a three-year-old bid answer still describes the production edge.
2. Separate logical diversity from physical diversity
Document handoff sites and common failure points at a level suitable for the customer. Two BGP sessions on one router are not router diversity. Two circuits in one duct are not route diversity. Two radios on one unprotected power supply are not power diversity. Two suppliers that both depend on the same wholesale tail may not be supplier diversity at the point that matters.
The public AS path cannot resolve any of these conditions. Cactus and its suppliers can, through circuit identifiers, demarcation records, diverse-entry statements and a controlled failure exercise.
3. Treat IPv6 as an operating service
An IPv6 plan should include allocated space, route authorisation, upstream carriage, customer delegation, resolver behaviour, firewall policy, monitoring and support. A pilot should prove that dual-stack customers reach independent test destinations over both families and that a family-specific fault does not cause unacceptable application delay.
If IPv4 and IPv6 share the same physical handoff, say so. The second family still improves address availability and protocol reach, but it should not be sold as protection from a common circuit or power failure.
4. Measure power at every dependency
State backup runtime under load for the edge router, upstream handoff, access switch, relay radio and customer-premises equipment included in the service. Test batteries rather than quoting nameplate capacity. Identify which side is responsible for grounding, surge protection and replacement. If generation is used, record start behaviour, fuel availability and the load that can actually be supported.
The historical proposal shows why this boundary matters: a service can be technically commissioned while leaving a decisive electrical dependency with the customer.
5. Put field recovery into the service promise
Define when the repair clock starts, what evidence opens a fault, which hours are covered, and which events pause the clock. Hold compatible radios, power units, optics and routers in known quantities. Verify access to rooftops and customer sites outside office hours. Exercise escalation when remote diagnosis fails.
A current support commitment should replace inference from the 2020 agreement and the mixed-quality website. Customers need the response applicable to their circuit, not an old contact matrix for another service.
Who bears the failure
The effect of a narrow edge differs by customer.
A residential user behind address translation may see every external application fail at once when the public routes disappear, while a neighbour on a mobile network can still load the Cactus support site. A business using a public Cactus address may lose inbound VPN, hosted services or remote cameras as soon as the route is withdrawn. A managed-connectivity customer may retain an access link and local network management but lose the internet path included in the contract. An institution buying a point-to-point service could remain connected between two local sites even if global transit fails, depending on where that circuit is switched.
None of these service designs is confirmed for a named current customer.
The operator also bears a peculiar communications risk. Because its website and mail are externally hosted, the public status surface can survive an AS135632 outage. That is potentially useful: Cactus can post updates from an unaffected connection. It can also be misleading if no status page distinguishes “our website is online” from “our subscriber routes are reachable.” A simple externally hosted status service with independent probes for all three prefixes would turn that separation into an operational advantage.
The economics are equally asymmetric. Maintaining a second upstream, spare router, batteries and field stock costs money even when nothing fails. A small public address estate does not reveal whether the revenue base can support that reserve. Nor does it prove that Cactus is small in subscriber terms; translation can place many users behind few addresses. What can be said is that three public routes concentrate the observable failure into a compact set. Monitoring every prefix from several external networks is technically straightforward.
The evidence grade is Medium, with a sharp physical limit
Cactus Network Solutions has more public operating evidence than its thin website first suggests. AS135632 is currently visible. Three IPv4 /24s were continuously observed in the first half of July. Hundreds of collector paths reached each route. APNIC maintains the organisation and response-contact records. The public domain and published contact points work. Historical commercial documents show Cactus offering wireless links and on-site support, and an official procurement evaluation records the company as a responsive telecom bidder in 2023.
The route evidence is strong for the narrow proposition it supports. AS135632 originated three IPv4 /24s at 08:00 UTC on 16 July 2026; no IPv6 route was visible; and every collected path entered through AS141421. The history is also clear that both the neighbour and route count have changed.
The physical and recovery evidence is weak. There is no verified current map of access fibre, towers, rooftop relays, handoff buildings or diverse entry paths. There is no public transit commit, utilisation level, customer count, backup runtime, spare stock or repair performance. The old proposal and support agreement identify plausible dependencies without proving the present design.
That combination is exactly why the title is a test rather than a verdict. One visible neighbour does not prove one cable. Three /24s do not prove a tiny business. No IPv6 does not prove imminent failure. But if the session carrying those routes stops and no alternate announcement appears, the public Cactus address space has nowhere else visible to go. The website may remain online in another ASN; the customer network's fate will be decided by circuits, routers, radios, power and people that Cactus has not made publicly inspectable.
The decisive evidence would be a controlled failover observed from outside: each /24 remains reachable through an independently usable alternate, customer traffic continues within a stated recovery interval, dual-stack service is tested where offered, and the equipment beneath both paths survives the same exercise. Until then, Cactus's resilience is not disproved. It is simply an operational claim waiting for the one test its public routing table makes impossible to avoid.