Summary

  • ONFIBER markets residential fibre tiers of 50, 120, 200 and 350 Mbps and antenna tiers of 30, 40 and 50 Mbps. Its address checker distinguishes the two forms of availability. That is useful evidence of a mixed access offer, but it is not a route map, a capacity audit or a measure of service quality.
  • LACNIC ties AS28447 to ONFIBER SA DE CV. RIPEstat identifies the ASN as announced and, for the 8-22 July 2026 observation window, lists six IPv4 prefixes, 1,280 IPv4 addresses and one IPv6 prefix. This makes ONFIBER visible at the public routing layer without revealing the physical paths beneath it.
  • RIPEstat currently observes AS270158 and AS274406 beside AS28447, while PeeringDB records ONFIBER as a Cable/DSL/ISP network with a general policy of Open. Neither source proves contractual upstream relationships, independent exits, carried traffic, spare capacity or failover performance.
  • The unanswered questions sit between a marketed access plan and a usable connection: fibre-route depth, antenna backhaul, convergence points, power backup, upstream arrangements, customer density, fault isolation, spares and repair capacity. Those are not reasons to dismiss ONFIBER. They are the evidence needed to judge resilience rather than mere availability.

A provider becomes visible in layers

The easiest way to misunderstand a regional access provider is to collapse every kind of visibility into one claim. A functioning retail site can show that a company is selling service. A registry record can show that an autonomous system number is assigned to a named organization. Route collectors can show that prefixes associated with that number are being announced. A network directory can show how the operator describes itself to potential interconnection partners. None of those observations is trivial, but none is a substitute for the others.

ONFIBER has evidence in each of those layers. The consumer-facing layer begins with recognisable access products: fibre plans, antenna plans, an address-based coverage check and a separate business proposition. The administrative layer begins with LACNIC's record for AS28447. The routing layer appears in RIPEstat, where the ASN is visible and announced. The interconnection-facing layer appears in PeeringDB, where the network is named ONFIBER SA DE CV and classified as a Cable/DSL/ISP.

That convergence is enough to move the company beyond a name on a directory page. The retail identity and routing identity point to the same organization. There is a public offer at one end and an observable internet number at the other. For a provider whose customers ultimately need traffic to cross from a local access link into the wider internet, that is the beginning of an intelligible operating surface.

It is only the beginning. These sources illuminate different edges of the service, not the path through the middle. They do not show which fibre strands, ducts, poles, antenna links or aggregation devices carry a given address. They do not show whether two apparent paths share the same physical crossing or power source. They do not show who receives a fault at night, which spare is available, or how long restoration takes. A provider can therefore be real, routed and commercially active while its resilience remains impossible to judge from public evidence.

The right conclusion is neither credulous nor dismissive. AS28447 gives ONFIBER a measurable internet presence. Its website gives the ASN a market context. The unresolved task is to connect those visible boundaries with evidence about the access route and the repair organization that keeps it usable.

Two public PDFs also sit in ONFIBER's web trail, but their text is not relied upon here. Their URLs alone cannot establish authorisation scope, exact coverage, legal terms or regulatory obligations.

The product menu reveals two access promises

ONFIBER's package page separates fibre from antenna service. The fibre menu presents tiers at 50, 120, 200 and 350 Mbps; the antenna menu presents 30, 40 and 50 Mbps. Those numbers are first-party offers, not independently measured speeds, yet the distinction between the two menus matters more than the individual tier labels.

It suggests that the company does not present every address as the same engineering problem. A fibre connection and an antenna-based connection may deliver the same broad customer outcome, internet access, while relying on materially different access paths. The fibre service requires a physical route to the premises or its immediate serving point. The antenna service requires a usable link to an antenna access system and, behind that link, backhaul into the rest of the network. The website does not describe those architectures in detail, so it would be wrong to supply one on ONFIBER's behalf.

It does, however, make clear that access method is a variable in the offer.

That variable changes how a buyer should read a speed tier. A headline rate describes a marketed service class. It does not disclose how capacity is shared, how traffic is aggregated, whether the path has an alternate, or what happens when a serving component is unavailable. Two customers buying plans with similar labels can have very different dependencies if one is reached by fibre and another by antenna. Even two fibre customers may traverse different amounts of shared plant before reaching a routed edge.

The tier ladder also says little about the difference between nominal capacity and repeatable performance. The public pages do not provide audited throughput distributions, latency, packet-loss measurements or busy-period behavior. They do not state how the advertised tiers map to upstream capacity. There is no public basis here for calling the plans either under-provisioned or resiliently engineered. The evidence supports only the narrower observation that ONFIBER markets several fibre and antenna service levels.

This is why product visibility must not be treated as network proof. The menus tell customers what they may buy. They do not tell an infrastructure analyst how the service is built. Their value is in defining the promise that deeper evidence would need to test: which access method is available, what service class is offered, and what operational system stands behind it when the link stops meeting that promise.

An address checker is a boundary, not a coverage map

The coverage page asks users to check an address and distinguishes fibre availability from antenna availability. That is a sensible retail boundary. Access networks are local by nature, and an operator cannot infer serviceability from a city name alone. The presence of an address check signals that ONFIBER expects availability to vary at a finer level.

But an address checker should not be converted into a geographic claim it was not designed to support. It does not reveal a complete service footprint. It does not show where the edge of a fibre build lies, where an antenna service can be installed, how many premises are passed, or how many addresses have active customers. A positive answer for one location would establish only that the company's sales system considers that address serviceable under its current rules. A negative answer could reflect physical reach, capacity, data quality or a commercial decision.

Without more information, the mechanism cannot be reverse-engineered into a route map.

The distinction is especially important when discussing resilience. Coverage and route diversity are different properties. A provider may be able to reach an address through one path while having no alternate path to it. It may also have multiple logical routes at a higher layer that ultimately converge on one access segment. The public checker does not expose those dependencies. It answers a sales question, not a failure-domain question.

Nor does it establish exact geography. ONFIBER's public posture is rooted in Aguascalientes, and its about page says it uses fibre and antenna solutions to reach areas where other providers may not arrive. That is a claim about its market purpose. It is not an audited boundary around every place where service exists. Without a verified route inventory or complete coverage dataset, broader statements about municipalities, neighbourhoods, towers or corridors would be speculation.

For a prospective customer, the checker is therefore the beginning of qualification. The next questions depend on the answer it gives. Is the proposed access fibre or antenna? Which parts of the path are shared? What installation work is required? What service and restoration commitments apply to that address? The public page can direct the conversation, but it cannot answer the engineering questions by itself.

Business connectivity raises the standard of proof

ONFIBER's business page does more than repeat a residential speed offer. It places connectivity beside point-of-sale systems, online billing, terminals and cloud services, and it uses the language of support and monitoring. That framing matters because these applications turn an internet link into an operating dependency.

When a household connection is unstable, the consequences can be serious and disruptive. When a commercial connection supports payment acceptance, invoicing or access to cloud systems, the interruption can also stop transactions and routine administration. The website is right to recognise that business buyers view connectivity through the work it enables. Yet the more consequential the use case, the more important it becomes to separate marketing language from operational evidence.

Support can mean many things: a channel for reporting incidents, extended service hours, proactive observation, escalation to a network team, or a contractual restoration process. Monitoring can refer to the provider's core systems, an individual customer link, or simply the ability to see whether equipment responds. The public page does not define the scope. It also does not publish verified availability, repair-time performance, escalation targets or the relationship between a monitored alert and a dispatched repair.

The absence of those details does not show that the capabilities are absent. It means the public claim has not yet been translated into a testable operating commitment. A business buyer should want the translation in writing: what is monitored, who is alerted, when the incident clock starts, which failures are covered, how status is communicated, and whether a second access path is actually independent of the first. None of those questions can be answered by a speed tier alone.

The mixed fibre-and-antenna portfolio makes this scrutiny more specific. A business address offered fibre may have a different failure and restoration profile from one offered antenna access. The backup option, if any, could share aggregation, upstream connectivity or power with the primary service. Calling two links different technologies does not prove that they are independent. The useful commercial conversation is about shared points of failure, not simply the number of boxes installed at the customer site.

ONFIBER's business proposition is therefore a reason to look more closely, not a reason to assume an outcome. It identifies the applications the company wants to support. Route-and-repair evidence would show how the provider intends to keep those applications connected.

AS28447 anchors the name to the public internet

The strongest non-marketing evidence in ONFIBER's public record begins with AS28447. LACNIC's RDAP service ties that autonomous system number to ONFIBER SA DE CV. The record includes a registration event dated 11 November 2022 and subsequent last-change events. RIPEstat independently presents the identity as AS28447 - ONFIBER SA DE CV and marks the ASN as announced.

An autonomous system number matters because it is used at the boundary where routing policy is expressed to other networks. Its public visibility indicates that ONFIBER is not only presenting an access brand; a network identity bearing its legal name is participating in the routing system. That is a stronger claim than a logo, domain or package page can support.

The registration date should still be handled carefully. It dates an event in the registry record. It is not necessarily the date the company was founded, the date service began, or the date its present network architecture came into use. Last-change events likewise show that the administrative record changed; without a detailed, verified account of each change, they should not be narrated as operational milestones.

The ASN also does not reveal the shape of the last mile. Border Gateway Protocol describes reachability between autonomous systems and toward prefixes. It does not identify the fibre route to a household, the backhaul behind an antenna connection, the location of an aggregation point or the ownership of any physical asset. A routed identity can remain visible even while a particular access segment is impaired. Conversely, a local access network can remain electrically active while its route to the wider internet is unavailable.

This separation is central to understanding ONFIBER. AS28447 gives analysts something concrete to observe over time: announced prefixes, routing status and neighbouring ASNs. It supports questions about the internet-facing edge. It cannot answer questions about installation density, route diversity, restoration practice or customer experience. The ASN makes the provider visible, but it does not make every dependency visible with it.

Seven route entries require careful reading

RIPEstat's announced-prefix view lists seven entries for AS28447 in the observation window from 8 July to 22 July 2026: 203.142.5.0/24, 38.158.203.0/24, 200.76.118.0/24, 38.158.202.0/23, 38.158.202.0/24, 38.226.104.0/24, and 2806:3f6::/32. The routing-status view summarizes the visible resources as six IPv4 prefixes, 1,280 IPv4 addresses, one IPv6 prefix and 65,536 IPv6 /48s.

Those figures are useful precisely because they are bounded. They show an observable set of routes associated with AS28447 during a named period. The presence of both IPv4 and IPv6 matters. So does the fact that the ASN is currently announced. For ongoing coverage, changes in this surface can be monitored rather than inferred from marketing.

The entries should not be casually added together or translated into customer scale. 38.158.202.0/23 and 38.158.202.0/24 overlap: one is a covering block and the other a more specific route within it. A list of route objects is therefore not the same thing as a list of disjoint address holdings. RIPEstat's aggregate of 1,280 IPv4 addresses is the more appropriate summary supplied by the routing-status view, but even that number describes address-space visibility, not active subscribers or simultaneous sessions.

The IPv6 /32 deserves the same restraint. Saying that it corresponds to 65,536 possible /48s describes the structure of the address space in RIPEstat's summary. It does not mean ONFIBER has allocated that many customer networks, serves that many sites, or has activated every part of the block. IPv6 planning intentionally provides very large address space. Utilization cannot be read from the theoretical subdivision count.

Nor does route visibility disclose capacity. A prefix can be announced over a constrained connection or over several well-provisioned paths; the route object alone does not say which. It does not show traffic volumes, congestion, committed bandwidth, burst headroom or the proportion of customers depending on a particular route. A stable announcement is evidence that reachability is being propagated, not a throughput certificate.

The most defensible reading is consequently modest but meaningful. ONFIBER has a dual-stack public routing surface associated with AS28447, with multiple visible IPv4 routes and one visible IPv6 aggregate during the observed window. That makes route-level monitoring possible. It does not close the gap between the routed edge and the service experienced at an address.

Adjacent ASNs are observations, not contracts

RIPEstat's neighbour view currently lists AS270158 and AS274406 beside AS28447. Neighbour observations can be one of the most tempting public signals to overstate. They show that routing data contains adjacency involving the ASNs. They do not, on their own, identify the commercial or operational meaning of that adjacency.

It would therefore be wrong to call AS270158 or AS274406 a contractual upstream on this evidence. A public routing relationship can arise in different contexts, and the collector view does not provide ONFIBER's contracts, invoices, service commitments or internal traffic policy. It does not say which party pays another, whether the relationship is primary or occasional, or how much traffic crosses it. The term "upstream" carries a business and topology claim that the observed adjacency alone cannot bear.

The pair also does not prove redundancy. Two neighbouring ASNs could represent two genuinely independent external paths, but they could also depend on shared facilities, shared transport, a common remote point, or arrangements that are not simultaneously usable for all routes. The public view here does not resolve those possibilities. It offers no verified failover test and no evidence about the physical path beneath either adjacency.

Even at the logical level, a list of neighbours is only a snapshot of what route collectors can observe. It may not describe every relationship, and visibility can depend on routing policy and collector vantage points. The fact that two ASNs appear is useful for forming questions and watching change. It is not a complete interconnection diagram.

For a business assessing continuity, the missing evidence is practical. Which external paths normally carry traffic? Are all customer prefixes eligible on each path? What happens when one adjacency disappears? How quickly does routing converge, and does the surviving path have enough usable capacity? Do nominally different external links share transport or power? These are ordinary resilience questions, but the answers would need to come from ONFIBER or measured performance, not from labels applied to a neighbour list.

AS270158 and AS274406 should thus remain exactly what the source supports: currently observed adjacent ASNs. That phrasing preserves the value of the evidence without turning a routing observation into an unsupported contract or resilience claim.

PeeringDB shows posture, not performance

PeeringDB adds another piece to the internet-facing picture. Its API contains a network entity for ASN 28447 named ONFIBER SA DE CV, points to ONFIBER's website, classifies the network as Cable/DSL/ISP, and records its general policy as Open.

This is consistent with the other public surfaces. The legal name and ASN align with LACNIC and RIPEstat; the network type aligns broadly with a company selling access. An Open general policy indicates how the network presents its willingness to interconnect in the directory. For peers and researchers, that is more informative than an absent record.

It remains directory evidence. An Open policy does not prove that a particular interconnection exists, that traffic is exchanged under uniform terms, or that capacity is available at a given place. It says nothing by itself about route diversity, congestion, traffic ratios, technical readiness or the time required to establish a session. Nor does the network type prove a specific physical access architecture. Cable/DSL/ISP is a directory classification, not an audit of ONFIBER's plant.

PeeringDB is therefore best read as posture. ONFIBER has made AS28447 legible in an ecosystem used for interconnection discovery, and the record invites a conversation under an Open policy. The operational value would become clearer with verified interconnection locations, current technical contacts, capacity context and observed sessions, none of which should be invented from the general policy field.

Taken with the registry and route data, the record reinforces identity. It does not solve resilience. The public internet edge is visible from several angles, but the number and independence of usable paths remain unproved.

The missing bridge is route depth

Between an address marked available and a prefix visible in global routing lies a chain of local and regional dependencies. For fibre service, that chain may include the customer drop, distribution plant, aggregation and transport to an internet-facing edge. The public sources do not disclose ONFIBER's version of that chain, so its exact topology should not be guessed. Yet the types of evidence needed to assess it are clear.

Route depth is not the same as route length. It describes how many layers of shared dependency sit between an individual connection and a point where traffic has a meaningful alternative. A customer may have a dedicated-looking drop that joins neighbours at the first distribution point. Several distribution branches may then share aggregation, transport or power. A second external routing adjacency cannot protect against a cut on the only local path to that edge.

This is why claims of "fibre" and "multiple neighbours" must remain separate. Fibre identifies an access medium in ONFIBER's offer. The neighbour view identifies observed routing adjacencies. Neither source shows whether the physical and logical paths form an end-to-end resilient service. Joining them into that conclusion would skip every dependency between the premises and the border.

Useful route evidence would answer concrete questions without requiring publication of sensitive engineering detail. ONFIBER could describe whether business services can be ordered with physically diverse entrances, whether access branches converge before aggregation, and how it verifies separation when a customer buys a secondary link. It could state whether diverse external services use independent transport and whether route failover is tested. An anonymised explanation of failure domains would be more valuable than a visually impressive but unverifiable map.

The current public record supplies none of that proof. It also supplies no basis for a negative conclusion. There is no evidence here that the network is single-homed at every layer, just as there is no evidence that it is diverse. The condition is uncertainty, not failure.

For analysts, that uncertainty sets the boundary of the article. AS28447 can be monitored at the routed edge. ONFIBER's address checker can reveal the access method offered to a particular prospective customer. The depth, convergence and ownership of the route connecting those two observations remain private. Until those facts are disclosed or independently measured, resilience should be treated as an open question.

Antenna access moves the question to backhaul

The antenna tiers broaden ONFIBER's reach proposition. Its about page says the company uses fibre and antenna solutions to serve areas where other providers may not arrive. That language gives the antenna offer a clear commercial role: it is presented as another way to connect an address, not merely as an accessory to the fibre menu.

The public pages do not specify the antenna system's topology, equipment, capacity or physical footprint. They do not provide a tower count, installation map or backhaul design, and none should be inferred. What can be said is that an antenna access path still needs a path beyond the radio link. Customer traffic must eventually reach aggregation and the routed internet surface represented by AS28447.

That makes backhaul the central unanswered question. The customer-facing link may be distinct from fibre to the premises while relying on fibre or another shared connection behind the antenna access system. Several serving points may converge on the same transport. An antenna offer and a fibre offer at nearby addresses could also converge farther into the network. The sources do not show whether any of those possibilities applies to ONFIBER.

Capacity is similarly opaque. The 30, 40 and 50 Mbps antenna tiers are marketed service classes. They do not state how many active users share a serving resource, what backhaul headroom exists, or how busy-period demand is managed. Customer density therefore matters twice: at the access system and along the shared backhaul. Without utilisation and design information, the tier label cannot be converted into a claim about repeatable throughput.

Repair differs too. A fault affecting an individual installation is not the same as one affecting shared access equipment or its backhaul. Restoration may require different skills, spares and access arrangements. Public support language does not reveal how ONFIBER distinguishes those cases or which one drives the expected repair time.

The antenna portfolio is thus important evidence of market reach, but not of engineering resilience. To cross that boundary, ONFIBER would need to explain the failure domains behind the service: where traffic converges, how capacity is monitored, what alternate backhaul exists where offered, and how field faults are isolated and restored. Those questions follow directly from the product, without assuming an unsupported physical network.

Repair capacity is part of the network

Infrastructure accounts often privilege assets because assets are visible. A fibre route can be drawn; an ASN can be queried; a prefix can be counted. The ability to repair service is harder to observe, yet for an access provider it is part of the delivered system.

A route is useful only while its components work or can be restored. That makes fault intake, diagnosis, field access, trained personnel, spare equipment and escalation authority operational forms of capacity. A provider may have enough bandwidth in normal conditions and still deliver poor continuity if it cannot locate or repair a failure quickly. It may also restore service well with a modest footprint if its dependencies are understood and its response is disciplined. Public routing data cannot distinguish those outcomes.

ONFIBER's business page uses support and monitoring language, which suggests that the company recognises this operational layer. The sources do not define it. There is no published, audited record here of repair-time performance, no outage history, no inventory of spares and no verified staffing model. Those omissions prevent both praise and criticism. They simply leave the repair promise unmeasured.

The most informative evidence would be distributional rather than anecdotal. An average restoration time can conceal a small number of very long incidents. A stronger disclosure would separate access methods and fault classes, showing how quickly fibre access, antenna access, shared backhaul and external routing incidents are detected and resolved. It would explain when the clock begins and whether planned work is excluded. Even without exact figures, a clear escalation and communication process would help customers understand what support means.

Repair proof also needs a boundary around responsibility. A customer problem can sit in local equipment, the access link, shared ONFIBER infrastructure, an external network or a service on the wider internet. Monitoring that merely reports loss of reachability may not locate the fault. Good operations depend on deciding which domain has failed and getting the incident to the party able to act. The public pages do not show how ONFIBER performs that handoff.

This is particularly relevant to business applications. A terminal that cannot reach a cloud service may look like a generic internet problem, while the cause could lie anywhere along the chain. Buyers need to know what ONFIBER will investigate, what evidence it can provide, and how escalation works when its own access remains up but an external route is impaired.

Repair capacity cannot be deduced from the existence of AS28447. But once AS28447 establishes that ONFIBER has a real routed surface, repair evidence becomes the next test of whether that surface supports a dependable access business.

Power turns diverse-looking paths into shared risk

Power backup is another gap that public routing and retail pages cannot fill. The sources do not describe ONFIBER's backup design, runtime, maintenance practice or the parts of the network covered by it. They do not identify facilities or serving sites. Any claim about generators, batteries or specific locations would therefore be unsupported.

The analytical point is narrower. Two network paths that look different can still share a power dependency. Fibre and antenna services can be technically distinct at the customer edge while converging on equipment that needs the same supply. Two external routing adjacencies can remain logically separate while depending on common powered infrastructure. Without a view of failure domains, technology labels and neighbour counts do not settle the question.

For customers, backup at the premises is only one side of continuity. Keeping a router or terminal powered does not help if the serving path is unavailable. Equally, a provider's network may remain available while the customer's own equipment loses power. A credible resilience discussion separates those domains and states which one each backup measure protects.

Useful disclosure need not reveal sensitive locations. It can describe design standards: which classes of network element receive backup, how runtime is sized, how backup condition is tested, and how prolonged loss is escalated. It can explain whether monitoring distinguishes commercial power failure from equipment or link failure. None of those details appears in the available public evidence for ONFIBER.

Power should consequently remain on the diligence list, not in the factual portrait. There is no basis here to call ONFIBER's design strong or weak. There is only a clear reason why apparent route diversity would need power evidence before it could be treated as dependable.

Customer density connects engineering to economics

The speed menus describe what ONFIBER offers; they do not describe how many customers share the infrastructure supporting each offer. Customer density is commercially sensitive, but it is also one of the variables that links regional-ISP economics to service quality.

Access networks carry large fixed costs. Physical reach, aggregation, backhaul, internet capacity, monitoring and repair readiness must be supported by revenue from the addresses served. Low density can make route expansion and spare capacity harder to justify. High density can improve the economics of investment while increasing the number of customers exposed to a shared failure. Neither condition is inherently good or bad. What matters is how capacity and restoration resources scale with demand.

ONFIBER's public evidence contains no customer count, number of passed premises, take-up rate or traffic profile. The IPv4 address total cannot be used as a substitute. Addresses may be allocated in different ways, and one visible address does not equal one customer. The IPv6 /48 capacity is even less suitable as a subscriber proxy because the address space is intentionally expansive. The address checker also cannot be sampled into a reliable footprint without knowing its data and decision rules.

This leaves a central economic question unanswered: whether the service tiers, shared capacity and support resources are aligned with the customer load in each part of the access network. A 350 Mbps fibre plan says nothing by itself about how many such plans can be active behind an aggregation point. A 50 Mbps antenna plan says nothing about the number of users sharing access or backhaul. Only utilisation and design evidence could make that connection.

The same applies to repair. A growing footprint may require more field capacity, more spares and better fault automation. If service reaches areas where alternatives may be limited, restoration capability becomes particularly important to the value of the offer. That is a reason to ask for evidence, not a basis for assuming that alternatives are absent at any specific location.

For investors or commercial partners, the useful metrics would therefore combine engineering and operations: customer concentration by failure domain, busy-period utilisation, capacity upgrade triggers, incident frequency by access method and restoration distributions. The public sources do not supply them. They define the questions that must be answered before route visibility can be translated into a view of operating quality.

What route-and-repair proof could look like

The most useful next disclosure would begin at the product boundary ONFIBER already presents. Fibre and antenna customers should be able to understand the broad path their service takes, the points where traffic becomes shared, and the options available for a genuinely separate backup. This need not include coordinates, asset inventories or security-sensitive diagrams. A plain account of dependency classes would be enough to improve diligence.

For fibre, the important distinction is between a second commercial circuit and a second physical route. ONFIBER could explain when diverse entry or aggregation is available, how separation is verified, and where independence can no longer be promised. For antenna access, it could explain how shared access and backhaul capacity are managed, what is monitored, and whether alternate backhaul exists for any service class. The aim is not to demand universal redundancy. It is to make the purchased level of resilience explicit.

At the routed edge, ONFIBER could clarify the roles of observed adjacencies without disclosing contract terms. It could state whether customer prefixes can fail over between independent external paths, how regularly that behavior is tested, and whether a surviving path is engineered to carry the relevant load. Such statements would add operational meaning to the neighbour view while avoiding the false inference that AS270158 and AS274406 must be contractual upstreams.

Repair proof should be similarly bounded. Published support hours, escalation stages and definitions of incident start and restoration would make the business-page language testable. Aggregated performance by access method and fault class would be stronger still. Customers do not need a list of individual incidents to understand whether restoration is usually measured in minutes, hours or longer; they need consistent definitions and a representative distribution.

Power can be addressed through standards rather than locations. The provider could describe which classes of shared equipment receive backup, how backup health is monitored and tested, and what communication occurs when expected runtime is at risk. Again, the point is not to infer that ONFIBER lacks these measures. It is to identify the evidence that would distinguish a designed capability from an unqualified promise.

Finally, the relationship between the address checker and service commitment could be made clearer. A positive availability result could identify access method, expected installation conditions, business support options and whether a separate route is available. That would turn the checker from a simple sales gate into the first step of informed service design.

These disclosures would not eliminate outages. They would make dependencies visible enough for customers and partners to choose intelligently. That is what route-and-repair proof is for.

What customers and partners can conclude now

A prospective customer can reasonably conclude that ONFIBER presents an active residential and business access offer associated with Aguascalientes, with both fibre and antenna service categories. The customer can use the company's coverage process to ask whether a specific address is considered serviceable and which access method is offered. The published tier names provide a basis for a commercial conversation.

A network analyst can reasonably conclude that ONFIBER SA DE CV is tied to AS28447 in LACNIC's registry, that RIPEstat sees the ASN announced, and that IPv4 and IPv6 routes are visible for it in the stated observation window. The analyst can monitor those routes and the currently observed adjacency to AS270158 and AS274406. PeeringDB adds a consistent network record and an Open general policy.

Neither person can reasonably conclude that ONFIBER has verified fibre-route diversity, redundant antenna backhaul, guaranteed uptime, audited service-level performance or a particular repair capacity. The sources do not reveal exact coverage, customers, towers, physical route ownership, facilities, outage history, backup design or contractual upstreams. The lack of public proof is not proof of lack, but it must remain a limit on the claim.

For a residential buyer, that limit suggests asking practical questions before installation: which access method applies, what equipment and shared dependencies sit in the path, how faults are reported, and what restoration expectations are offered. For a business buyer, the questions should extend to written support scope, monitoring, escalation, capacity, backup options and physical independence. For a network partner, they should extend to routing policy, eligible prefixes, path capacity and failover behavior.

The answers may differ by address and service class. That is normal for an access network. What would be misleading is to turn a general website, an ASN or a neighbour observation into one universal answer.

Visibility is the start of accountability

AS28447 changes the quality of the ONFIBER story. Without it, the company would be visible mainly through its own sales pages. With it, ONFIBER SA DE CV has a public routing identity that can be associated with announced IPv4 and IPv6 space and watched over time. LACNIC, RIPEstat and PeeringDB provide different forms of corroboration around that identity.

The website then explains why the routing identity matters. ONFIBER is not presenting AS28447 as an abstract internet resource. It is selling access, by fibre and antenna, to households and businesses whose terminals, billing and cloud applications may depend on the connection. The public route surface is therefore attached to a concrete service promise.

That attachment creates accountability, but it does not complete the evidence. The route collector sees the edge of AS28447, not the route to a customer's door. The package page sees the tier, not the load on shared infrastructure. The neighbour view sees adjacency, not a contract or independent transport. The business page invokes support and monitoring, not measured restoration. Each source is useful because its limits are clear.

ONFIBER is consequently visible enough to merit serious coverage. It has a coherent market and network identity, a mixed access offer and a routable surface that is more informative than a simple company profile. The remaining questions are also specific enough to matter: how deep the fibre paths run before they converge, how antenna traffic is backhauled, how external paths are contracted and tested, how power is protected, how customer density is managed, and how faults are repaired.

Those questions should not be answered with suspicion or marketing. They should be answered with bounded evidence. Until that evidence is available, the sound judgement is precise: AS28447 proves that ONFIBER can be seen on the public internet; it does not yet prove that every marketed access path can withstand a route failure or be restored on a dependable timetable. The access promise becomes infrastructure-grade only when route and repair are visible together.

Sources