Summary

  • LACNIC binds the exact company name SOLUCIONES WISP S.A. and handle AR-SWSA9-LACNIC to AS265777, IPv4 range 181.191.64.0/22 and IPv6 range 2803:4fc0::/32.
  • A 27 July 2026 RIPEstat snapshot showed AS265777 to 329 of 330 checked IPv4 peers and all 324 checked IPv6 peers, a control-plane observation rather than an uptime, coverage or capacity measure.
  • The checked pairs AS265777 plus 181.191.64.0/22 and AS265777 plus 2803:4fc0::/47 were RPKI-valid, but two checks do not establish complete route security.
  • PeeringDB adds self-reported exchange and facility context, while customer delivery, physical path diversity, contracts, installed capacity and operational continuity remain unproved.

1. The Exact Company Name Anchors the Network Identity

The strongest starting point is not a marketing description but an exact-name match across public systems. The BTW directory identifies SOLUCIONES WISP S.A. under the canonical slug soluciones-wisp-s-a-ar. Its public page resolves with the expected name rather than a soft-404 shell, and the public directory API returns the same company and slug. That gives the investigation a defined directory entity rather than a loose brand string.

LACNIC supplies the corresponding number-resource identity. Registrant handle AR-SWSA9-LACNIC carries the exact organization name SOLUCIONES WISP S.A. The autonomous-system record for AS265777 refers to that handle, as do the records for the company's IPv4 and IPv6 ranges. Agreement at this level makes the link much more defensible than a match inferred from a website colour scheme, search snippet or abbreviated trade name.

The link still has limits. A registry record names the holder associated with Internet number resources; it does not describe shareholders, directors, beneficial ownership, corporate group structure or every customer-facing name the business may use. The records examined here also do not establish that the company owns every router, fibre segment, radio, building or power system involved in delivering connectivity.

The directory dossier itself leaves several commercial and operating questions open. That is not a reason to discard the identity. It is a reason to separate the durable technical join from broader business claims. The public evidence supports saying that the exact directory company has an ASN and registered address resources. It does not support turning that statement into a complete corporate profile.

This distinction matters because network accountability depends on knowing which entity sits behind a routing identifier. AS265777 creates a stable point from which route origins, authorization data and observed interconnection can be examined. The company name establishes who is associated with that point. Everything beyond that boundary still requires evidence designed for the question being asked.

2. AS265777 Is a Control Point, Not a Service Map

An autonomous-system number identifies an administrative routing domain. In practical terms, AS265777 lets networks and observers associate public BGP announcements with a stable origin. Filters, route-origin authorizations, monitoring alerts and historical comparisons can all refer to the same number even when individual prefixes or paths change.

That makes the ASN operationally meaningful. If a prefix unexpectedly originates from another autonomous system, or if AS265777 stops appearing in collector views, the number gives investigators something concrete to examine. It also provides counterparties with an identifier for routing policy and technical coordination.

The number does not reveal where customers live. It does not enumerate municipalities, homes passed, enterprises connected, towers operated or neighbourhoods served. An ASN can originate routes from one location or many, through owned infrastructure or purchased services. None of those alternatives is encoded in the number itself.

Nor does the ASN establish access technology. The company name includes WISP, and PeeringDB classifies the network under Cable/DSL/ISP, but public number-resource records do not show whether a particular customer receives fixed wireless, fibre, Ethernet, leased capacity or another product. Naming and classification can guide questions; they cannot replace product-level proof.

LACNIC records the ASN on 25 July 2017. That date belongs to the number-resource record. It should not be presented as the launch date of the business, the first day of customer service or evidence of uninterrupted operation since 2017. Registration history and commercial history are related only when separate records connect them.

The useful conclusion is narrow. SOLUCIONES WISP S.A. controls a public routing identity with observable current activity. The ASN makes a portion of its network behaviour visible and comparable. It does not make the underlying service footprint transparent.

3. The IPv4 /22 Is a Registered Boundary, Not a Subscriber Count

LACNIC assigns the range from 181.191.64.0 through 181.191.67.255 to AR-SWSA9-LACNIC. Expressed as 181.191.64.0/22, it contains 1,024 IPv4 addresses. The holder name and handle match the ASN record, so the allocation belongs within the same number-resource identity.

Those 1,024 addresses cannot be converted into 1,024 customers. An address may be used by infrastructure, assigned dynamically, held in reserve, shared through carrier-grade translation, delegated to a business customer or left unused. One subscriber can consume multiple public addresses, while many subscribers can appear behind one address. The registry does not expose internal assignment policy.

The range is not a coverage polygon either. Geolocation products may associate addresses with a city or region, but those labels often derive from registration, observed egress, commercial inference or user reports. Even a correct egress location does not show every place where access is sold. A routed block describes logical reachability, not the physical path from a customer site.

Directly registered IPv4 space can nevertheless matter. It can give an operator continuity of public addressing across some supplier changes and a clearer identity for routing and reputation management. Those are operational options, not guarantees. Their value depends on routing competence, contractual arrangements, equipment, filtering, monitoring and the condition of the delivery network.

The current routing observation shows the covering /22 announced by AS265777. That is evidence that the registered resource has a running control-plane expression in the sampled period. It still says nothing about how many addresses carried traffic, which services used them or whether end users experienced stable connectivity.

Treating the /22 as a bounded administrative resource preserves both sides of the evidence. The company has a visible, registered IPv4 footprint. Utilization, customers, geography, physical plant and service quality remain separate questions.

4. The IPv6 /32 Provides Hierarchy, Not Proof of Deployment Depth

The same LACNIC handle holds 2803:4fc0::/32. IPv6 allocations are deliberately large enough to support structured delegation without reproducing IPv4 scarcity. A /32 can be divided into many customer and infrastructure prefixes, giving an operator room to design a consistent addressing hierarchy.

Mathematical capacity is not operational adoption. The allocation does not show how many downstream /48s or /56s have been assigned, which routers support IPv6, whether residential equipment receives stable prefixes, or whether help-desk and security practices work equally across both address families. Those details require configuration, measurement or customer-facing evidence.

Public routing does show more than registration alone. RIPEstat observed 2803:4fc0::/47 and 2803:4fc0::/48 originated by AS265777 during the sampled interval. The /48 is contained within the /47, and both are contained within the registered /32. They are not separate allocations that should be added together to inflate the resource footprint.

The more-specific records can reflect routing policy, staged deployment, segmentation or traffic engineering. Their exact purpose is not published in the sources examined here. Prefix length by itself cannot establish the number of sites, customers or upstream paths behind an announcement.

IPv6 visibility is valuable because it shows running dual-stack capability at the public routing edge. It does not prove that every product is dual-stack or that the IPv6 customer experience matches IPv4. Native delivery, prefix delegation, DNS behaviour, customer-premises equipment and application compatibility all sit beyond what the route collectors report.

The precise statement is therefore modest but useful: SOLUCIONES WISP S.A. holds an IPv6 /32, and AS265777 currently originates visible IPv6 routes within it. Claims about deployment scale, address use or universal customer availability would exceed the evidence.

5. The Announced Prefixes Show Current Running State

RIPEstat's announced-prefix response covers the observation interval from 13 to 27 July 2026. It includes the IPv4 covering route 181.191.64.0/22 and the two IPv6 records 2803:4fc0::/47 and 2803:4fc0::/48. This dated view matters because it distinguishes resources merely registered on paper from resources appearing in BGP.

The route set is small enough to interpret carefully. There is one visible IPv4 covering prefix. On IPv6, the /48 is nested inside the /47. Counting the two IPv6 records as independent blocks would overstate the amount of distinct space represented. The parent allocation remains the /32 recorded by LACNIC.

An announcement demonstrates reachability information, not traffic volume. A prefix can appear in routing tables while carrying little traffic, and heavy traffic can use a route that looks identical to collectors. BGP does not expose bits per second, customer sessions, congestion or utilization. It tells other networks where an origin claims the address space can be reached.

The record also lacks physical context. It does not identify the router that generated an announcement, the building where a session terminates, the fibre or radio path feeding that router, or the power systems supporting it. One logical origin can rely on several physical paths, or several visible records can share one failure domain.

Dated routing observations are best used for comparison. Future checks can determine whether the same covering routes remain present, whether more-specifics appear or disappear, and whether the origin changes. A change would justify investigation; it would not explain itself.

For accountability, this is already meaningful. AS265777 was not merely an assigned identifier at the snapshot. It was expressing both IPv4 and IPv6 routes in the public control plane. The evidence supports operational visibility while leaving traffic, topology and delivery performance open.

6. Peer Visibility Is Broad, but It Is Not an Uptime Result

At the 27 July 2026 snapshot, RIPEstat reported that 329 of 330 checked IPv4 RIS peers saw AS265777. All 324 checked IPv6 peers saw it. Those ratios indicate broad visibility from the collector set and offer a concrete baseline for future route monitoring.

The result should not be described as 99.7 percent uptime for IPv4 or 100 percent uptime for IPv6. The denominator is a set of routing peers, not minutes in a service period. A peer seeing an origin says that a BGP path was available from that vantage point. It does not say that a customer's access circuit, DNS resolver, application or destination performed correctly.

Collector coverage is extensive but finite. RIS does not represent every network, and policy can cause one peer to receive a route that another does not. A missing observation can reflect filtering, topology, session state or timing rather than an outage. The one IPv4 peer that did not see the ASN is therefore not a documented customer-impact event.

The complete IPv6 observation is similarly bounded. It shows that the origin was broadly visible among the checked IPv6 peers at that moment. It does not establish uninterrupted visibility before or after the query, and it cannot reveal short withdrawals between samples.

Still, the numbers can guide incident triage. If a future complaint coincides with a large collapse in collector visibility, the public routing layer becomes a plausible part of the fault domain. If visibility remains near the baseline, investigators should still examine access, transport, local power, addressing, DNS and customer equipment.

The distinction protects the evidence from being asked to answer the wrong question. The snapshot is strong evidence of broad dual-stack control-plane visibility. Service availability, recovery time and end-to-end quality require measurements and operating records that are not public here.

7. Two RPKI-Valid Checks Narrow One Security Question

The checked IPv4 pair combines origin AS265777 with 181.191.64.0/22. RIPEstat returned a valid RPKI result and showed a route origin authorization covering the same /22 with a maximum length of /24. Within the captured state, the origin and prefix length were consistent with published authorization metadata.

The checked IPv6 pair combines AS265777 with 2803:4fc0::/47. It also returned valid, based on an authorization covering 2803:4fc0::/32 with a maximum length of /64. The /47 sits inside that authorized range and remains within the permitted maximum length.

These checks answer a specific question: did each selected origin-prefix pair match relevant ROA data at the time of the query? They do not prove that every possible prefix originated by the ASN is valid. They also do not prove that every network on the Internet performs route-origin validation or rejects invalid routes.

RPKI does not authenticate the complete AS path, prevent route leaks, secure router management or guarantee that an authorized operator will never make a mistake. A valid route can still encounter congestion, equipment failure, configuration error or malicious traffic. Origin authorization is one security control among many.

The results are nevertheless material. They show that the company has not left these two visible route expressions entirely outside the public authorization framework. The IPv6 authorization is particularly flexible, allowing more-specifics down to /64 while keeping AS265777 as the authorized origin.

The right conclusion avoids both exaggeration and dismissal. Two current checks validate against published security metadata, strengthening confidence in those exact origin-prefix combinations. A comprehensive assessment would enumerate every active announcement, inspect authorization freshness, monitor state changes and examine operational handling of invalid or unexpected routes.

8. Maximum Length Is a Policy Choice with Operational Consequences

The IPv4 authorization allows more-specific routes down to /24. Because the registered block is a /22, that policy leaves room for the operator to announce the covering route, two /23s or four /24s without making those more-specifics RPKI-invalid, provided the origin remains AS265777.

Such flexibility can support traffic engineering, selective advertisement, mitigation or operational transition. It also expands the set of route lengths that the authorization accepts. Whether that trade-off is appropriate depends on the intended routing design and the operator's monitoring and change controls.

The IPv6 authorization permits lengths down to /64 inside the /32. That is a very broad range of possible more-specifics. It does not mean that all such routes are present, desirable or accepted by common Internet routing policy. Many networks filter very long IPv6 prefixes regardless of ROA validity.

Maximum length should therefore be read as an authorization boundary, not a deployment inventory. It tells validators which more-specific origin announcements may be considered valid. It does not state why they exist, where they terminate or how traffic reaches customers behind them.

Operational discipline matters because a permissive authorization can make some unintended announcements valid from an RPKI perspective. Monitoring still needs to detect route count changes, unusual more-specifics and departures from expected policy. RPKI status and route intent are not the same thing.

For SOLUCIONES WISP S.A., the selected visible prefixes fit the checked authorization boundaries. That is a positive, narrow finding. Assessing whether the maximum-length choices reflect current operational needs would require the operator's intended-prefix list and change history, neither of which is supplied by the public responses.

9. Five Observed Neighbours Are Clues, Not Contract Labels

RIPEstat's neighbour view observed five autonomous systems adjacent to AS265777 in sampled paths. AS11014, AS3356 and AS6057 appeared on the left side of the origin, while AS269870 and AS64000 appeared on the right side. The response provides a view of path adjacency, not a contract register.

The left and right labels describe where an ASN appeared relative to AS265777 in the sampled paths. They should not be translated automatically into provider, customer or peer roles. Route collectors can see paths shaped by policy, aggregation, propagation and vantage point. Commercial relationships require independent evidence.

The list also does not establish physical diversity. Two neighbouring ASNs may be reached through the same building, conduit, power domain or underlying carrier. Conversely, one ASN relationship may be delivered across multiple locations and paths. Logical diversity and physical diversity overlap only when topology evidence connects them.

Frequency in observed paths is not a capacity measurement. A commonly seen neighbour might carry substantial traffic or very little; BGP path counts do not reveal utilization. Nor do they show contractual commitments, service levels, pricing, settlement terms or failover priorities.

The neighbour data is still useful for monitoring. It identifies adjacent numbers whose appearance or disappearance can be tracked, and it frames questions about dependency concentration. If the set changes sharply, investigators can compare timing with route visibility and service reports.

The responsible wording is simple: five adjacent autonomous systems appeared in the sampled route-path data. Anything about paid transit, settlement-free peering, customer relationships, exclusive paths or guaranteed backup would require stronger evidence than adjacency alone.

10. PeeringDB Adds a Declared Interconnection Layer

PeeringDB maps ASN 265777 to SOLUCIONES WISP S.A. and also displays the name Internet WISP. It classifies the network under Cable/DSL/ISP, places it in South America and records an open peering policy. These fields add useful operating context, especially when read beside the authoritative LACNIC identity.

PeeringDB is operator-maintained. Its purpose is to help networks exchange interconnection information, but the entries are not independent measurements of traffic, capacity or service quality. A record can be accurate and useful without carrying the evidentiary weight of a registry allocation or collector observation.

The profile's traffic and prefix-count fields should therefore remain labelled as declarations. They may help a prospective counterparty decide whether to contact the network, but they do not establish measured throughput or current route inventory. Public routing data remains the better basis for describing announcements observed at a specific time.

The open peering-policy label signals a stated willingness rather than a binding promise. It does not reveal technical requirements, port availability, commercial exceptions, response times or whether any specific session exists. Those questions belong to direct coordination.

The alternate name Internet WISP may describe how the network presents itself, but it does not replace the exact company identity. SOLUCIONES WISP S.A. remains the name joined across the directory and LACNIC records. Keeping the two names in their proper roles avoids merging a presentation label with legal-resource evidence.

Used carefully, the PeeringDB record complements the harder technical sources. It helps locate declared interconnection context and operator intent. It cannot independently prove what traffic flows, how much capacity exists or whether the delivery network survives a failure.

11. AR-IX CABASE Interfaces Show Declared Exchange Participation

PeeringDB's exchange-interface response lists operational interfaces for AS265777 at AR-IX CABASE. That is a stronger statement than a general interest in peering because it associates the ASN with specific operator-maintained interface records at an exchange platform.

The word operational in this setting describes the status recorded in PeeringDB. It should not be treated as a real-time health check. The response does not measure packet loss, session state, route count, utilization or recent maintenance. A current exchange looking glass or direct operational confirmation would be needed for those questions.

An exchange interface can shorten paths or create additional interconnection options, but it does not automatically prove redundancy. Multiple interfaces can share a switch fabric, building, transport provider, power feed or operational team. Resilience depends on the failure domains beneath the logical entries.

The exchange record also does not identify every counterparty. A shared exchange environment creates the possibility of bilateral or route-server sessions, yet the public interface list does not prove which sessions are active or how traffic is routed under failure conditions.

For a regional network, declared exchange participation is economically relevant because it can affect latency, transit use and access to local traffic. Those outcomes must be measured rather than assumed. The available data supports saying that AS265777 has declared operational interfaces at AR-IX CABASE, not that the arrangement delivers a quantified performance benefit.

The interfaces fit the broader control-surface thesis. SOLUCIONES WISP S.A. has a registered ASN, visible routes, selected valid RPKI states and declared exchange attachment. That combination exposes points where policy and coordination can be examined. It still leaves the customer-facing path largely out of view.

12. Facility Listings Do Not Establish Ownership or Capacity

Separate PeeringDB records place the network at Cabase BUE and Cabase LPL. These location entries identify declared presence associated with AS265777. They can help a network engineer understand where an interconnection conversation might begin.

Presence does not mean ownership. The company may use colocation, a partner, remote connectivity or another arrangement. The public records do not state who owns the building, rack, fibre, switching equipment or access circuit. They also do not describe the duration or contractual status of the presence.

The two listings should not be converted into two independent sites for resilience scoring. Physical diversity depends on routes, conduits, power, equipment, carriers and operational procedures. Even locations in different cities can share upstream dependencies, while remote exchange access may place equipment somewhere other than the named facility.

Capacity is equally absent. A facility entry does not disclose port speed, committed information rate, headroom, peak utilization or congestion. PeeringDB may display traffic ranges at the network level, but those remain self-reported and do not allocate capacity to a particular location.

The location names can support bounded questions. Which exchange ports are local rather than remote? Which fibres or carriers reach them? Are routing sessions and power domains independent? What monitoring detects a partial failure? What restoration commitments apply? None of those answers should be invented.

By resisting the temptation to equate a listing with a facility asset, the evidence stays useful. It identifies declared interconnection locations without making documentary claims about premises, equipment or capacity that the public data cannot sustain.

13. Registry Facts and Running Code Must Remain Distinct

LACNIC and RIPEstat describe different layers. LACNIC identifies who is associated with an ASN and address ranges. RIPEstat captures what route collectors observed and how selected origin-prefix pairs evaluated against RPKI data. Neither layer replaces the other.

A registered prefix can be absent from BGP without losing its registry identity. It may be reserved, temporarily withdrawn or used in a way not visible to the sampled collectors. Conversely, a route can be visible while questions remain about authorization, resource holder details or intended policy.

For AS265777, the layers align on the core facts. The exact company holds the ASN and allocations; the ASN is announced; IPv4 and IPv6 routes within those allocations are visible; and the two selected origin-prefix pairs validate. This is a stronger reality layer than either registration or routing alone.

The alignment does not make the registry an operating certificate. LACNIC records do not certify uptime, customer service, topology or business performance. Route collectors do not adjudicate corporate ownership or contractual rights. RPKI validates origin authorization under a defined model, not every security property.

This separation improves troubleshooting. If a name or allocation changes, the registry layer needs attention. If visibility changes, the routing layer becomes relevant. If validation changes, ROA or announcement policy may need investigation. Conflating them makes the diagnosis less precise.

The company is therefore observable at several linked control points without becoming fully transparent. Public systems establish identity, resource boundaries, routing state and selected security metadata. The physical and commercial delivery system remains a different evidentiary problem.

14. Number Resources Create Portability Options, Not Independence

An ASN and directly registered address space can give an operator more control over public network identity. Addressing may remain stable through some supplier changes, and routing policy can be expressed under the same origin number. These features can reduce certain forms of lock-in.

Portability is not automatic continuity. Changing upstreams or interconnection can require route filters, session configuration, authorization updates, testing, maintenance windows and coordination. Stable numbers do not remove the work of moving traffic safely.

The physical network can remain concentrated even when the routing identity is portable. Access lines, backhaul, exchange transport, buildings, power systems and repair teams may depend on a small set of suppliers. No public ASN record measures those dependencies.

Operational skill is another constraint. Direct routing control creates responsibility for filtering, security metadata, monitoring, incident response and communication. The presence of valid RPKI checks is relevant, but it does not demonstrate the complete change-control or incident-management practice behind them.

Portability also has limits at the customer edge. A business can preserve public prefixes while still facing disruption from equipment changes, layer-two migration, DNS dependencies or customer-premises configuration. The address identity solves only part of the transition problem.

AS265777 and its allocations should therefore be understood as a set of operating options. Current route visibility shows those options are being exercised in the public control plane. Whether they translate into bargaining power, supplier diversity or rapid recovery remains unproved.

15. Delivery Resilience Lives Below the Public Route

A visible BGP route rests on a chain of systems that the route itself does not describe. Customer access reaches aggregation, transport connects locations, routers exchange reachability, facilities provide space and power, and people monitor and repair failures. Any link in that chain can affect service.

The current evidence does not identify owned fibre, leased circuits, wireless towers, ducts, cabinets, exchange transport or customer-premises equipment. It does not say where AS265777's routers are installed or which physical paths connect them. A generic visual of interconnection hardware cannot fill that gap.

Power continuity is also unknown. A route can remain visible through one location while a neighbourhood access node loses power. The opposite can happen when a routing session fails even though much of the physical access plant remains available. Battery autonomy, generator coverage and restoration priorities require direct evidence.

Two facility listings and five route-path neighbours do not prove independent failure domains. Logical choices can converge on the same conduit, building or carrier. Establishing resilience would require topology, supplier, power and operational information detailed enough to identify shared dependencies.

Human processes matter as much as equipment. Escalation coverage, access to sites, spare availability, configuration review and customer communication can determine recovery time. Public registry and routing data cannot reveal whether those arrangements are mature or fragile.

The resulting gap is central rather than incidental. SOLUCIONES WISP S.A. has an observable public network edge. The path from that edge to a customer's working service remains unverified. Any claim about resilience should wait for evidence from the delivery layer.

16. Customer Experience Cannot Be Read from BGP

BGP answers where prefixes are advertised, not whether a user can complete a video call, reach a bank, resolve a domain or receive the contracted speed. A customer can experience severe local impairment while the provider's routes remain visible worldwide.

Access congestion is one example. The ASN may appear normally in every collector while an oversubscribed wireless sector, fibre aggregation link or local handoff degrades. Collector visibility cannot show queue depth, packet loss or latency on those segments.

DNS and addressing create other failure modes. A route may be healthy while a resolver fails, a delegated IPv6 prefix changes unexpectedly, or customer equipment applies a broken firewall rule. Those symptoms can look like an Internet outage without involving BGP withdrawal.

Conversely, a routing change may affect some destinations more than others. Policy, filtering and path selection can create partial reachability even when the origin remains broadly visible. End-to-end probes from relevant customer locations are needed to characterize such failures.

No public source in the bounded set supplies speeds, service-level commitments, complaint rates, outage history or repair intervals. Those omissions should not be filled with assumptions based on the company name, address-block size, exchange presence or RPKI status.

The public network identity still benefits customers indirectly by creating accountability. It makes route origins and authorization states monitorable, and it gives technical counterparties a stable reference. Customer experience becomes measurable only when that control-plane view is joined with access and application evidence.

17. Procurement Needs Evidence at Each Layer

A buyer considering connectivity from a regional provider should begin by separating identity, control-plane operation and delivery assurance. The first layer is relatively clear here: the exact company is bound to AS265777 and registered IPv4 and IPv6 resources.

The second layer is also partly visible. Both address families appear in public routing, broad peer visibility was observed, two selected RPKI checks were valid, and operator-maintained records describe exchange and facility context. These points support technical due diligence but do not complete it.

Delivery assurance needs different documents. A buyer would need a serviceable-address confirmation, access-medium description, demarcation details, installation responsibilities, performance commitments, maintenance windows, escalation paths and restoration targets. None can be derived from the ASN.

Resilience claims should be tested against failure domains. Questions should cover route diversity, carrier diversity, building entrances, power, exchange connectivity, customer-premises equipment and staff coverage. A diagram is useful only when it distinguishes owned, leased and third-party components and identifies shared dependencies.

Security diligence should also be specific. The two valid RPKI checks are a positive input, but a buyer may ask how unexpected origins are monitored, how route filters are maintained, which contacts receive alerts and how changes are approved. Those practices determine how the metadata is used.

The evidence can therefore shorten procurement without closing it prematurely. It verifies a real public routing identity and highlights where targeted questions belong. It cannot substitute for product terms, site-specific design or operating commitments.

18. Incident Review Should Preserve the Layer Boundaries

When service fails, broad labels such as network outage can hide the actual fault domain. An effective incident review begins by asking which observable layer changed and which did not. AS265777 provides a useful control-plane reference for that process.

If the origin disappears from most collectors, investigators can examine routing sessions, announcements, filters and upstream reachability. If the origin remains broadly visible, attention may shift toward access, transport, local power, DNS, customer equipment or a destination-specific path.

RPKI state offers another signal. A route becoming invalid could result from an unexpected origin, a more-specific outside the maximum length or a stale authorization. A valid result does not rule out every routing problem, but a state change can identify a focused line of inquiry.

Exchange and neighbour records can help organize contacts, yet they should not be treated as a live dependency map. The parties visible in sampled paths or operator-maintained profiles may not correspond to the exact path used by an affected customer at the time of failure.

A credible post-incident account would include timestamps, affected services, observed route and authorization changes, physical findings, restoration actions and remaining uncertainty. Public routing data can corroborate parts of that timeline but cannot supply the whole narrative.

This layered approach avoids two common errors: declaring an Internet-wide incident from a local symptom, and declaring the network healthy because routes stayed visible. Both the control plane and the delivery path deserve evidence matched to their function.

19. A Compact Monitoring Set Can Track Meaningful Change

The public facts are suitable for repeatable monitoring. The durable set begins with the exact company name, handle AR-SWSA9-LACNIC, AS265777, IPv4 allocation 181.191.64.0/22 and IPv6 allocation 2803:4fc0::/32. Changes to those records would merit identity review.

The running set includes the observed IPv4 /22 and IPv6 /47 and /48, their origins, peer-visibility ratios and neighbour observations. These values can change with routing policy and collector state, so every comparison should retain its timestamp and vantage-point limits.

The security set includes RPKI status for active origin-prefix pairs, covering ROAs and maximum lengths. Monitoring should detect not only invalid states but also unexpected valid more-specifics, because authorization and intended routing policy are not identical.

Operator-maintained interconnection data can be tracked separately. Exchange interfaces, facility listings, traffic ranges and peering policy may change without immediate BGP effects. Any change should remain labelled as a declaration until corroborated by an operational source.

Alert thresholds should avoid turning harmless variation into a conclusion. One missing collector peer or a temporary path change may not affect users. Larger sustained changes deserve investigation, while impact claims require customer or active-measurement evidence.

This monitoring set makes the public edge more accountable without pretending to monitor the access network. It provides a disciplined way to notice changes, ask better questions and preserve uncertainty where the available systems are silent.

20. The Defensible Conclusion Is Visibility with an Open Delivery Boundary

SOLUCIONES WISP S.A. is not merely a name in a directory. Authoritative LACNIC records bind the exact company to AS265777, an IPv4 /22 and an IPv6 /32. Dated routing observations show both families active and broadly visible. Two selected origin-prefix pairs validate against published RPKI authorizations.

Operator-maintained PeeringDB records add declared exchange interfaces and facility context in Argentina. Those entries can support interconnection inquiry, but they are not independent proof of traffic, capacity, physical assets or redundancy. Route-path neighbours are similarly useful observations without being commercial contract labels.

The combined evidence establishes a real control surface. Registration provides identity and resource boundaries. BGP shows running public routes. RPKI adds selected origin-authorization metadata. Exchange records point to declared coordination locations. These layers reinforce one another without becoming interchangeable.

The customer-delivery boundary remains open. Public data does not establish access technology, service area, utilization, installed capacity, physical topology, transit terms, uptime, outage history or recovery design. It does not show how many customers depend on each path or which dependencies are shared.

That is not a reason to diminish what is known. A visible routing identity and valid checked authorizations are meaningful facts for a regional operator. It is a reason to describe them with precision rather than turning them into promotional claims.

The most useful public assessment is therefore an accountability statement: AS265777 makes SOLUCIONES WISP S.A.'s number resources, current route origins and selected security metadata observable. Proving delivery resilience requires a different body of evidence, drawn from the physical network, supplier relationships, operating practice and customer-facing performance.

Sources