Summary

  • LACNIC identifies CORPORACION CONEXTELECOM S.A.C as the holder of the active, directly allocated AS269975, registered on 18 March 2020 with a Lima address. RIPEstat observed the ASN announced at 16:00 UTC on 21 July 2026 and associated it with one IPv4 prefix and one IPv6 prefix in the examined period.
  • PeeringDB reports a 1,000 Mbps operational port at JumboIX Peru and presence at IPTP San Isidro Lima, Cirion Lima - LIM1 and Equinix LM1 - Lima. Those disclosures identify interconnection points; they do not prove facility ownership, spare capacity, transport diversity between sites or the route taken to a customer's premises.
  • Conex markets fibre service to homes, PYMEs and enterprises and claims two fibre routes, radio backup, automatic restoration, a continuously operating NOC and direct connection to major submarine cables. These are first-party statements, not independent evidence of physical separation, restoration time, cable capacity or performance under load.
  • The useful diligence question is how the visible ASN, exchange port and facility handoffs connect to the advertised access network. Customers need route-level documentation, demarcation details, failure scenarios, backup limits and measured restoration evidence before treating logical visibility as physical resilience.

Visibility starts with the ASN

An autonomous system number is a useful piece of infrastructure evidence because it gives a network a stable public identifier. In Conex Telecom's case, AS269975 connects several otherwise separate disclosures. The LACNIC record names the legal holder. RIPEstat shows that the number was visible in routing at a stated observation time. PeeringDB uses the same ASN to describe an exchange connection and facility presence. The company's own site supplies the customer proposition that sits behind those technical records.

This is more than a branding trail. A buyer can distinguish the operator from similarly named businesses, identify the network resource being discussed and ask questions about specific prefixes and interconnection points. A supplier that can be located in registry and routing data is easier to examine than one represented only by a sales page. The ASN creates a starting coordinate for technical diligence.

But it is only a logical coordinate. It does not reveal where every fibre runs, which ducts are shared, who owns the access segment, how power is protected, or whether two services that appear separate converge at the same cabinet or building entrance. It does not show the usable bandwidth available to a particular customer. It cannot demonstrate the time required to repair a cut, replace equipment or obtain physical access at an interconnection site.

The distinction matters because a visible route can coexist with a fragile service path. Routing records may show that an ASN and its prefixes are present while saying nothing about the number of physical paths underneath that presence. Conversely, a small visible routing surface need not mean poor service. It means only that the public logical evidence is narrow and must not be stretched into a physical conclusion.

For Conex, AS269975 makes the investigation possible. It does not settle it. The proper use of the number is to organize the evidence chain from legal identity, to announced resources, to exchange and facility handoffs, and finally to the customer's access circuit. Every step after the logical edge needs its own proof.

The registry fixes the identity boundary

LACNIC's RDAP record is the strongest public anchor for the operator's identity. It associates AS269975 with CORPORACION CONEXTELECOM S.A.C, describes the autonomous-system resource as an active direct allocation and gives the address Narciso de la Colina 605 in Lima. It records the autnum registration date as 18 March 2020 and shows the related registrant entity last changed on 2 September 2024.

These facts provide a useful legal and administrative boundary. The company name should be preserved as S.A.C even though different wording appears elsewhere on the company's site. A footer variation is not sufficient reason to replace the registry identity. Customers can use the LACNIC name and address to reconcile the entity on a proposal, contract, invoice and service order.

The registry record does not allocate operational responsibility. It does not establish that the named company owns the fibre used for every service, owns equipment at every disclosed facility or directly employs every person involved in installation and repair. It does not say which third parties provide backhaul, ducts, tower access, power, field maintenance or upstream connectivity. An ASN holder and an asset owner may be the same party in some places and different parties in others; this record does not decide that question.

Nor does the active status certify service quality. It indicates the standing of the numbered resource in the registry, not whether a residential plan reaches its advertised speed, whether an enterprise circuit has diverse entrances or whether a NOC meets a response target. The registration and update dates help establish chronology, but they are not operating metrics.

The identity evidence is therefore solid within a deliberately narrow frame. CORPORACION CONEXTELECOM S.A.C is the registry holder tied to AS269975 at the stated Lima address. Everything about customer serviceability, physical assets and recoverability needs evidence from the relevant commercial and technical layer.

Two observed prefixes define a small public edge

RIPEstat's announced-prefixes view observed two resources for AS269975 during the period from 7 July to 21 July 2026: the IPv4 block 190.89.28.0/24 and the IPv6 block 2803:16e0::/32. Its AS overview also reported AS269975 as announced at the 16:00 UTC observation point on 21 July. Together, these records show a currently visible dual-stack routing identity at the time examined.

The observation is meaningful. It links the legal identifier to routes seen in the global routing system and shows that the network is not represented solely by a dormant registry entry. The IPv4 and IPv6 records also give customers two specific resources to monitor when evaluating reachability, path changes or route-origin behavior.

Yet two observed prefixes are not an inventory of the service network. RIPEstat warns that announced-prefix results can exclude routes with very low visibility across its full-feed collectors. The time window is also bounded. It records what the system observed, not everything the operator may use in every context, and not what will necessarily be visible at another moment. A customer should not convert the list into a claim that Conex has exactly two routes, two links or two physical networks.

The IPv4 /24 and IPv6 /32 are also different kinds of objects from retail speed labels. Prefix size says nothing about available throughput. A network may announce a large address block over a constrained path, or a small address block over a well-provisioned one. Addressing capacity and transmission capacity are not interchangeable. The records support route identification, not a bandwidth calculation.

The most defensible reading is precise: AS269975 was visible, and RIPEstat associated the two named prefixes with it in the examined period. That makes route-level inquiry possible. It does not show how customer traffic reaches those routes, how many independent physical paths support them, or what happens when one component fails.

Routing consistency shows alignment, not resilience

RIPEstat's routing-consistency data adds another layer. It shows both 190.89.28.0/24 and 2803:16e0::/32 in BGP and in whois or IRR data, with LACNIC identified as the authority. This is a useful alignment signal: the observed route origins and the registered routing information point toward the same ASN for the two prefixes at the query time.

That alignment reduces one kind of ambiguity. A customer or peer can see that the prefixes being discussed are not merely mentioned on a marketing page. They appear in both routing observations and registry-related data. It also gives an operator a concrete baseline against which to investigate a future origin change or disappearance.

Routing consistency is not a resilience score, however. It does not report fibre-path separation, router redundancy, power protection, spare equipment, congestion, packet loss or repair staffing. A prefix can be consistently originated through one vulnerable dependency. Two consistent prefixes can share the same transport and equipment. The fact that IPv4 and IPv6 are both represented does not prove that their failure domains are separate.

Nor should a consistent record be read as a permanent guarantee. Routing is observed at a time, and registry data can change. What matters operationally is whether monitoring detects deviations and whether the operator can explain and correct them. For an enterprise customer, the useful follow-up is to agree which origin and path conditions will be watched, who receives an alert and what constitutes a service-affecting routing event under the contract.

The data therefore supports confidence in attribution, not in recovery. It helps answer, "Which network is this?" It does not answer, "How will this service survive a physical or operational failure?" That second question lies below and around BGP, in the parts of the network that the public routing view cannot expose.

AS7195 is a clue, not an upstream map

The same routing-consistency response lists AS7195 as an import and export peer visible in BGP but not in whois at the query time. This is worth reporting because it identifies a specific observed adjacency around AS269975. It gives a customer or analyst a place to begin asking how traffic enters and leaves the Conex network.

The phrasing must remain narrow. The result does not establish that AS7195 is Conex Telecom's only upstream, its primary upstream or the sole path carrying customer traffic. It does not describe the commercial relationship between the two networks. It does not show the physical location of the handoff, its contracted capacity, its utilization, its failover arrangement or the portion of traffic that follows it.

The absence of the same adjacency from whois or IRR in this response should not be turned into a misconduct claim. It is a difference between two data views at a particular time. Operational routing can be visible without the relationship appearing in the registry-derived field being compared. The useful question is whether the operator can document the adjacency, its role and the alternatives available if it becomes unusable.

For resilience diligence, the observed AS7195 relationship creates a dependency question rather than an answer. Is there another logical path? If so, is it physically independent? Do two upstream sessions terminate on different devices and at different sites, or do they converge before reaching the customer access network? Which prefixes are advertised on each path, and how is failover tested? None of those details can be inferred from the single observed adjacency.

AS7195 should therefore appear in the analysis as a bounded routing clue. It sharpens the inquiry around upstream concentration, but the public evidence does not support a complete topology. A serious assessment needs current routing policy, physical handoff and failover evidence from Conex itself.

PeeringDB gives the network a commercial shape

PeeringDB's record for ASN 269975 names CORPORACION CONEXTELECOM and the Conex Telecom brand, classifies the network as Cable/DSL/ISP and gives its scope as South America. It describes the traffic profile as mostly inbound, lists self-reported traffic in the 1-5Gbps range, and records one internet exchange and three facilities. The profile also points to the company's website.

These fields are useful because they place the ASN in an operating context. The Cable/DSL/ISP classification is consistent with a business selling access rather than a network resource held for a wholly unrelated purpose. A mostly inbound pattern is plausible for an access provider whose customers consume more content than they send, but the label remains self-reported. It is not a measured traffic trace available in the public record examined here.

The 1-5Gbps range requires similar discipline. It provides an order-of-magnitude statement chosen for the PeeringDB profile. It does not show peak traffic, committed transit, exchange utilization, headroom, customer demand, link oversubscription or growth. It also cannot be allocated across home, PYME and enterprise customers. Treating the top of the range as capacity would be especially misleading because reported traffic and provisioned capacity are different quantities.

PeeringDB's count of one exchange and three facilities is likewise a presence map, not a resilience diagram. It says where the network reports interconnection or facility relationships. It does not disclose whether all sites are active in the same way, whether traffic can shift among them or whether the transport joining them follows independent paths.

The profile makes Conex more legible, but most of its operational fields are declarations by the network. They are valuable leads for verification. A buyer can ask for current interface statistics, contracted handoff details and a diagram that reconciles the PeeringDB entries with the proposed customer service. Until then, the profile gives shape to the network without proving its strength.

The JumboIX port is a hard boundary, not a capacity promise

The most concrete interconnection item is the PeeringDB NetIXLAN entry. It lists an operational 1,000 Mbps port for Conex at JumboIX Peru, with IPv4 address 196.61.191.244 and IPv6 address 2a03:9d41:7::244. This is a more specific disclosure than a broad claim to be present at an exchange. It identifies the exchange, port speed, status and interface addresses in one record.

A 1,000 Mbps port can support a useful peering relationship, but the number cannot be treated as customer-usable capacity. It is the nominal port speed in the disclosure. The record does not show average or peak utilization, the number of peers, the volume of traffic exchanged, any rate limit, reserve margin or the capacity of paths feeding the port. It does not show whether the port is dedicated to one function or how its traffic relates to the self-reported 1-5Gbps network range.

The word operational also has a bounded meaning. It reports the state of the exchange connection in the PeeringDB entry. It is not an uptime history, an availability guarantee or proof that every customer can reach every relevant destination through that port. A current operational status can change, and a working exchange interface can still depend on transport and equipment outside the exchange fabric.

The dual-stack addresses are useful for technical confirmation. They demonstrate that the listed exchange connection includes both IPv4 and IPv6 addressing, while RIPEstat separately observed an IPv6 prefix originated by AS269975. But those facts do not establish identical routing policy, traffic volume or failover behavior across the two protocols. Each needs to be monitored on its own terms.

For a customer, the port should lead to a set of questions. Which traffic is eligible to use JumboIX? What path links Conex's access network to the exchange? What happens if that path, the Conex router or the exchange port fails? Is traffic shifted to a documented alternative, and has the shift been tested under realistic load? The 1,000 Mbps disclosure marks a real interconnection boundary. Resilience depends on everything connected to either side of it.

Three facilities do not automatically make three paths

PeeringDB's facility records list Conex at IPTP San Isidro Lima, Cirion Lima - LIM1 and Equinix LM1 - Lima. The entries matter because they identify three named Lima-area points at which the network reports presence. That is enough to ask site-specific questions rather than accepting a vague claim of metropolitan reach.

It is not enough to say that Conex owns, operates or controls any of those facilities. A network can be present through a cabinet, cage, port, cross-connect, remote arrangement or service supplied by another party. The public rows do not define Conex's property interest, space allocation, equipment inventory or access rights. They also do not establish that every listed presence is currently used for the same service offered to a particular customer.

Most importantly, three facility names do not prove three independent routes. Two sites may be connected through common ducts, common transport providers, shared street segments, the same building entrance or the same upstream equipment. The records do not show the physical paths among San Isidro and the two listed Lima sites, nor the path from any of them toward customers in Chorrillos. Counting pins on a facility list is not a substitute for tracing fibre.

The entries nevertheless improve the quality of diligence. A buyer can ask which proposed service handoff occurs at which facility, who owns the equipment at that point, how Conex personnel or contractors obtain access, what power arrangement applies and how traffic is moved if that location becomes unavailable. If a second facility is offered as backup, the provider can be asked to show the transport and operational separation that makes it a true alternative.

The fair conclusion is presence without inferred diversity. The three disclosures indicate a broader interconnection footprint than a single anonymous point. Their resilience value remains conditional on physical route, equipment, power and operating evidence that PeeringDB does not supply.

The retail proposition reaches beyond the public network map

Conex's website markets internet service in Chorrillos and divides its offer among home, PYME and enterprise customers. It promotes fibre access, quick installation, support and local personnel. It also lists contact channels and the Narciso de la Colina 605 address in Surquillo, Lima, aligning the public-facing business with the address found in the LACNIC identity record.

This customer proposition is broader than the network evidence visible through the ASN. The public technical records identify routing resources and interconnection points. They do not define the streets, buildings or premises that are serviceable, the access technology used at each address or the boundary between Conex-owned assets and third-party infrastructure. The website's focus on Chorrillos is a market statement, not a route map.

That gap is normal in the sense that operators rarely publish every access path. It is still commercially important. A customer's resilience is shaped by the specific physical route from its premises to the operator's network, not merely by the operator's presence at an exchange or data centre. A provider can have sound interconnection and still deliver one customer over a single vulnerable entrance. It can also have local access alternatives that do not appear in public routing data. Only service-specific evidence distinguishes those cases.

The segmentation among home, PYME and enterprise users also suggests different expectations, but the website alone does not define the service terms attached to each class. A plan label does not reveal whether bandwidth is committed, contended, shaped or subject to another condition. Nor does a general support claim establish an enterprise restoration commitment.

Conex's sales pages therefore show the intended demand side of AS269975: people and businesses buying access in Lima. They do not show how each advertised service reaches the visible network edge. That missing middle is where customers should concentrate their questions.

Plan labels should not be mistaken for delivered throughput

The residential pages display plan labels from 500 Mbps to 1.5 GB, while the PYME offer shows labels from 100 Mbps to 600 Mbps. Elsewhere, the company presents carrier ethernet from 10 Mbps to 1 Gbps. These figures are commercially relevant because they define the scale at which Conex is inviting customers to compare offers.

They need careful transcription. The residential upper label is shown as 1.5 GB, which is not enough by itself to determine the intended transmission-rate unit. It should not be silently converted into 1.5 Gbps or another measure without clarification from the provider. More broadly, a displayed speed does not say whether the number is a maximum, a committed information rate, a burst level, an access-port setting or another plan definition.

The public evidence does not include independent throughput tests, congestion measurements or performance under simultaneous demand. It also does not show how the retail plan labels relate to PeeringDB's self-reported 1-5Gbps traffic band or the 1,000 Mbps JumboIX port. Adding those numbers together would create a false capacity model. They refer to different layers and may have been recorded at different times.

For home and PYME customers, useful questions include what speed is expected at busy periods, how performance is measured, whether the advertised value applies in both directions and what remedy follows persistent underperformance. For enterprise and carrier-ethernet buyers, the inquiry should go further: committed bandwidth, handoff type, latency and loss objectives, measurement location, maintenance treatment and restoration terms should be stated in the order.

The economic significance is straightforward without needing an unsupported conclusion about Conex's margins. A regional provider must match sold demand with access, aggregation, peering and transit resources. Public plan labels reveal the promise to the market. They do not reveal whether the underlying network has enough headroom at the moment and place a customer needs it.

Mostly inbound traffic frames the dependency question

PeeringDB describes Conex's traffic as mostly inbound. As a self-reported profile field, this should not be treated as a measured ratio, but it helps frame the operating question. A provider serving access customers would expect much of the traffic demanded by those customers to arrive from content and services elsewhere. The resilience of inbound paths can therefore matter directly to the experience being sold.

The field does not identify where that traffic comes from. The JumboIX port may carry some locally exchanged traffic; the observed AS7195 adjacency may carry some traffic; other relationships may exist outside the narrow public evidence. Nothing in the records supports a complete split among peering, transit and private interconnection. Nor can the 1-5Gbps self-reported band be assigned to a particular source.

This uncertainty matters when a sales offer emphasizes high access speeds. A fast customer-facing link does not guarantee equivalent performance to every destination. The end-to-end result depends on aggregation and interconnection beyond the premises. If a material share of demand uses one constrained or failure-prone dependency, an access port can remain up while customer experience deteriorates. That is a scenario to test, not a condition established here.

A buyer can turn the mostly inbound description into practical questions. Which external paths carry the destinations important to the business? Which of those paths have alternatives? How does Conex manage congestion or route around a failed interconnection? What measurements can a customer see, and from which points are they taken? For enterprise service, the answer should distinguish the local access segment from performance beyond the Conex network.

The PeeringDB field is thus an analytical cue, not a verdict. It directs attention toward the capacity and recoverability of incoming traffic paths while leaving the actual topology and utilization to be demonstrated.

Two fibre routes and radio backup need a physical definition

Conex states that its network uses urban and interurban fibre and advertises two fibre routes plus radio backup. If physically and operationally independent, that design could materially improve continuity. The public site, however, does not provide route drawings, duct information, entrance details, radio specifications, capacity limits or failover results. The claim remains a first-party description whose practical meaning depends on those missing facts.

"Two routes" can describe several very different arrangements. The fibres may leave a customer building through separate entrances or share the same one. They may follow different streets or occupy the same duct. They may terminate on different devices or converge on one chassis, power source or facility. They may be owned by Conex, leased from one provider or assembled from multiple suppliers. None of these possibilities can be selected from the public evidence.

The radio backup is equally undefined. The website establishes that Conex says such a backup exists; it does not identify its coverage, spectrum arrangement, throughput, power, line-of-sight constraints or the services eligible to use it. A radio path capable of maintaining basic management or selected business traffic may not carry the aggregate load normally transported by fibre. That observation is a diligence principle, not a statement about Conex's actual radio system.

Automatic restoration also requires a trigger and a target. Does traffic move after loss of light, loss of a routed neighbor, a performance threshold or a manual decision? Which customer services participate? How long does detection take, and what happens to active sessions? Does restoration mean that any connectivity returns, that the contracted bandwidth returns or that a defined application remains usable? The sales wording does not answer.

For a customer relying on resilience, Conex should be able to map the claimed routes from the service demarcation to the relevant network nodes, identify shared segments and state the backup's usable limits. A controlled test should then demonstrate the transition and recovery. Without that evidence, two fibres and a radio path are components in a narrative, not proof of an independent service design.

Direct submarine-cable language needs an ownership and route boundary

The website also claims direct connection to the main submarine cables. This is potentially important language for an operator whose customers need international connectivity, but it is too broad to establish a physical or commercial fact on its own. The public material does not name a cable system, landing station, capacity contract, wavelength, operator or route from Conex's network to a landing point.

"Direct" can have different commercial meanings. It might refer to a relationship that avoids some intermediary at one layer, a connection obtained through a partner, a path to capacity associated with a cable system or simply a short way of describing international reach. The available evidence does not permit a choice among those interpretations. It certainly does not show that Conex owns submarine-cable assets or has its own physical cable-landing access.

The distinction matters because international resilience depends on more than the name of a cable. A customer needs to understand the contracted service, the handoff, the terrestrial route to the relevant interconnection, any shared dependencies and what alternate path applies when the preferred route is unavailable. Two products associated with different cable names can still share terrestrial infrastructure, while one well-designed service may have protections not visible in marketing copy.

Conex's PeeringDB facilities and JumboIX presence do not fill this gap. They show domestic interconnection disclosures in Lima, not a submarine topology. The observed AS7195 adjacency also does not identify a cable path. None should be combined into an invented route to the coast or beyond.

The claim is best treated as a request for particulars. Name the service and counterparties, define what direct means, identify the relevant physical and contractual boundaries, state the capacity available to the customer's service and document the restoration design. Until then, the submarine-cable language indicates an intended connectivity proposition, not verified cable access.

A 7x24x365 NOC is not the same as a restoration clock

Conex says it operates a 7x24x365 network operations centre and offers support, local personnel and automatic restoration. Continuous monitoring and reachable support can be valuable, but the public statement does not provide staffing levels, monitored systems, escalation steps, field coverage, mean repair results or customer-specific service commitments. It should be attributed as the company's claim, not presented as audited operating performance.

A NOC can observe and coordinate without being able to complete every repair remotely. Physical restoration may depend on building access, a field technician, a fibre contractor, spare equipment, a facility operator or an upstream provider. The time to acknowledge an alarm is different from the time to diagnose it, dispatch help, reach the fault, obtain permission to work and return the service to its contracted condition.

Automatic restoration covers another boundary. A routing or transport system may move traffic around one failure, but a successful switch does not necessarily restore full capacity or every application. The public page does not define which faults are covered, whether failover is automatic end to end, how often it is tested or what residual risk remains. It also does not establish that the radio path supports the same traffic level as the primary fibre service.

Customers should therefore ask for a clock with named stages. When does Conex detect an event? When is the customer notified? What starts the response timer? When is a field resource assigned? What condition counts as restored? If service returns at reduced capacity, how is that reported and remedied? Historic, anonymized performance against those stages would be more informative than a general promise of permanent vigilance.

The NOC claim is credible as a description of intended operating coverage only within its wording. The evidence needed for resilience lies in repeatable outcomes: detection, communication, failover, repair and full restoration under defined conditions.

The missing middle runs from the premises to the exchange

The public record describes both ends of a potential service chain more clearly than it describes the middle. At one end, Conex markets fibre access to customers in Chorrillos and broader offers for homes, PYMEs and enterprises. At the other, AS269975 is visible with two prefixes, one JumboIX port and three facility-presence disclosures. What is not public is the physical and operational path connecting a customer's demarcation to those network edges.

A useful diligence map begins at the premises. It identifies the building entrance, access medium, termination equipment and power dependency. It then follows the service through street routes, aggregation points and any third-party handoffs. It continues to the routers that originate or receive traffic for AS269975, the facilities where those routers or connections are present, and the exchange or upstream paths available beyond them.

Every transition has an owner and a failure mode. A customer may own equipment after the demarcation while Conex controls the access link. A landlord may control access to a riser. A transport supplier may own part of the fibre. A facility operator may control entry to a room. An upstream network may control a wider path. The public evidence does not assign these roles for Conex's services, so the map must be built from the actual order and design.

The map should also identify convergence. Two access circuits can meet at one pole, duct, aggregation device or power source. A radio backup can depend on the same rooftop access or local power as the fibre termination. Two interconnection facilities can be joined by one metro transport path. These are scenarios to rule in or out with evidence, not assumptions that they exist.

Once the chain is visible, the role of the public technical data becomes clearer. The prefixes and ASN identify the logical destination. JumboIX and the three facilities identify possible interconnection boundaries. They do not supply the route from the customer to those boundaries. Conex's resilience case will be strongest where it can close that missing middle with current, service-specific documentation.

A buyer needs an evidence package, not a longer slogan

The first part of a useful evidence package is identity and service scope. The contract should use the legal entity that will provide the service, reconcile it with CORPORACION CONEXTELECOM S.A.C where appropriate and identify any third parties responsible for material parts of delivery or repair. The order should state the premises, demarcation, service class, bandwidth definition and whether the arrangement is residential, PYME, enterprise internet or carrier ethernet.

The second part is a physical route statement. For a service sold as resilient, it should show the two claimed fibre paths at a level sufficient to identify common building entrances, street segments, ducts, aggregation points and facilities. Sensitive route detail need not be published to the world, but the customer or an independent reviewer needs enough evidence to test independence. The radio backup should be described by coverage, expected usable throughput, power dependency, activation logic and services protected.

The third part is the logical and interconnection design. Conex should reconcile the proposed service with AS269975, the observed prefixes, the role of the JumboIX port, the observed AS7195 adjacency and any additional paths it relies on. The purpose is not to demand that every network relationship be public. It is to show which alternatives exist for the customer's important traffic and whether they avoid the same failure domain.

The fourth part is capacity evidence. Plan labels, the PeeringDB 1-5Gbps range and the 1,000 Mbps exchange port should remain separate. A customer needs the bandwidth promised at its handoff, the measurement method, any contention or shaping terms, the capacity available during backup operation and the point at which performance is assessed. Recent utilization can help, but it must be tied to the interfaces relevant to the proposed service.

The fifth part is operations. The provider should define monitoring coverage, incident notification, severity, escalation contacts, field dispatch, access authority, spare strategy and the stages of restoration. If a NOC is continuously available, the customer should know what it can do directly and what requires another party. If automatic restoration is material to the sale, test results should show the triggering event, transition time, traffic effect and post-failover capacity.

Finally, the package needs change control. Routes, facilities, upstreams and service terms can change after installation. The customer should be told when a material dependency or resilience assumption changes, and the design should be reviewed after such a change. Evidence is not a one-time procurement ornament. It is the maintained description of the service being relied upon.

Failure scenarios are more revealing than component counts

Counting two fibre routes, one radio backup, three facilities and one exchange port can create an impression of redundancy without showing how the components behave together. Scenario testing is a better discipline because it asks whether the service outcome survives a specific loss.

One scenario is failure of the customer's primary fibre access. The relevant result is not merely whether a backup interface becomes active. It is whether the radio or second fibre path carries the defined customer service, at what capacity, after what transition, and with which applications affected. The public material gives no result, so this needs a controlled demonstration.

A second scenario is loss of the device or power source where two access paths converge. If both routes terminate on the same equipment, route diversity may not protect that failure. This article does not assert such convergence at Conex. It identifies the test required to establish that the advertised paths do not share an unacceptable point.

A third scenario is loss of the JumboIX connection or the transport feeding it. Monitoring should show which traffic moves elsewhere, how paths change and whether the alternative has enough capacity. The observed AS7195 adjacency may be relevant, but its role cannot be assumed. A fourth scenario is loss of access to one listed facility. The response should identify which services are affected and whether another site is truly operationally independent.

A fifth scenario is a field repair outside ordinary conditions. The NOC may detect the problem immediately, yet restoration can still depend on site access, technicians or a supplier. Measuring each stage reveals whether continuous monitoring translates into continuous capability to act.

These tests turn broad claims into service evidence without requiring an unrealistic promise that nothing will fail. The aim is to understand what fails together, what capacity remains and how restoration proceeds. Conex's public footprint provides enough named components to design the questions. It does not provide the answers.

Logical visibility is the beginning of the resilience case

AS269975 gives Conex Telecom a clear public network identity. LACNIC ties it to CORPORACION CONEXTELECOM S.A.C and a Lima address. RIPEstat observed the ASN and two prefixes in July 2026, with routing and registry-related data aligned for those resources. PeeringDB adds a 1,000 Mbps JumboIX Peru port and three facility-presence disclosures. The company's website connects that technical footprint to an access business serving homes, PYMEs and enterprises.

Those facts are enough to establish visibility. They are not enough to establish customer-usable capacity or physical resilience. The 1,000 Mbps port is not proof of spare bandwidth. The 1-5Gbps profile is self-reported traffic, not provisioned headroom. Facility presence is not ownership or diverse transport. Two advertised fibre routes are not proven separate paths. Radio backup has no public capacity or test result. A NOC claim has no public restoration clock. Submarine-cable language has no named cable or route boundary.

This is not a finding that Conex lacks the capabilities it advertises. It is a finding about the current evidence. The operator may have stronger designs, contracts and operating results than are visible in the eight public records considered here. If so, the shortest path to a stronger resilience case is to show the relevant physical and operational proof to customers.

The decisive chain begins at a particular premises, follows the access route through aggregation and facility handoffs, reaches the routers and interconnections supporting AS269975, and includes the people and procedures needed when automatic recovery stops. Every link should have an owner, a capacity boundary, a failure mode and a restoration action.

Conex has made itself findable at the logical layer. The question now is whether its access service is equally legible underneath. Until route separation, backup limits and restoration performance are demonstrated for the service being purchased, AS269975 should be read as an invitation to diligence, not a certificate of resilience.

Sources