Summary

  • LACNIC's RDAP record identifies Telecentro S.A. as the registrant of AS27747, but an autonomous system number is a routing identity rather than a physical network map.
  • PeeringDB records declared exchange and facility presence. Those entries help with interconnection, but they are maintained directory data rather than an independent measurement of every live path.
  • Telecentro says its Lomas del Mirador data centre has four medium-voltage feeders, 2N standby generation, N+1 UPS and battery arrangements, N+1 cooling and a fibre ring to four hubs. The claims describe a design; they do not disclose enough evidence to verify failure independence, usable reserve or recovery performance.
  • A 2025 ENACOM interconnection document names new SIP ports in Rosario, Cordoba and Tucuman. It records contractual telephone-network interconnection points, not the topology or resilience of Telecentro's internet backbone.
  • A 2016 ENACOM resolution documents one customer's 2014 service interruption and a sanction. It is relevant evidence about that case, not a network-wide reliability statistic or a description of current operations.

Image note: The featured image is a realistic editorial illustration of generic network and data-centre dependencies. It is not a photograph of Telecentro's facility.

Start with the question the records can answer

A useful infrastructure investigation begins by asking a narrow question. Who is recorded for a network number? Where does a network say that it interconnects? What equipment does a company say is present at a facility? Which service event did a regulator actually examine? Problems begin when an answer to one of those questions is silently stretched into an answer to all the others.

The public record for Telecentro illustrates the difference. LACNIC's Registration Data Access Protocol, usually called RDAP, returns a structured record for autonomous system 27747. It labels the resource as a direct allocation and names Telecentro S.A. as the registrant. This is authoritative evidence about the registry entry. It gives other networks and investigators a stable identifier and a recorded organisation to contact.

PeeringDB supplies another layer. When checked for this article, its public profile identified Telecentro as AS27747, described the network as a cable, DSL and internet service provider, and showed declared connections at the AR-IX exchange. It also listed facilities in and around Buenos Aires, including Cabase BUE, Cirion Buenos Aires BUE1, Pacheco Datacenter EZE1, Telecentro's Lomas del Mirador site and Telxius Barracas. These entries make the network's declared public edge easier to understand.

Telecentro's current company page adds physical design claims about its data centre. ENACOM documents add two different regulatory records: a 2025 interconnection expansion and a 2016 ruling about a much older customer case. Each source is useful because it records a different part of reality. None should be asked to certify a system it was not designed to test.

That distinction is not a technical loophole. It is the difference between an identity card, an address book, a product description, a contract and an incident finding. All five can be accurate while leaving important operational questions unanswered.

What AS27747 means in ordinary language

The internet is not one centrally controlled network. It is a collection of networks operated by companies, universities, governments, content providers and other organisations. These networks exchange information about which groups of internet addresses they can reach. An Autonomous System Number, or ASN, is the public number attached to one of those routing domains.

A simple analogy is a city made of many privately managed road systems. Each road operator tells neighbouring operators which destinations can be reached through its entrances. AS27747 is a label that lets other networks recognise routing announcements associated with Telecentro's public network. It helps routers apply policies consistently and helps engineers identify the network involved in a route.

The word autonomous does not mean sovereign, isolated or free from suppliers. It means that the network presents a routing policy to other networks. An operator can lease fibre, use another company's building, buy transit, connect at a shared exchange and still operate its own autonomous system. It can also operate more than one ASN or participate in services that involve other routing identities.

Networks exchange reachability information mainly through the Border Gateway Protocol, commonly shortened to BGP. A BGP announcement says, in effect, that traffic for a group of IP addresses can be sent toward a particular autonomous system. Other networks choose paths using technical and commercial rules. Those choices can change when capacity is added, maintenance begins, a link fails or policy is revised.

The ASN does not contain a list of every cable, switch, power feed, street cabinet, customer modem or employee. It does not say which path a particular packet is using at this moment. It does not prove that a backup circuit enters a building through a separate duct. It does not show how long generators can run or how a cooling fault is handled.

AS27747 is therefore meaningful and limited. It identifies a routing domain in the public coordination system. It does not transform that coordination record into a blueprint of Telecentro's complete operating network.

Why the registry is a ledger rather than a resilience certificate

Number resources need dependable records. Two unrelated networks cannot safely announce the same addresses without coordination, and autonomous system numbers must remain unique enough for routing policy to work. Regional internet registries maintain the chain of allocations, contacts and events that supports this coordination.

The RDAP record for AS27747 performs that job. It records a direct allocation and identifies Telecentro S.A. as the registrant. The record also exposes administrative, technical and abuse-contact roles. During a routing incident, that information can help another operator determine which organisation is recorded for the resource and where coordination should begin.

An accurate registry entry is an operational asset, but it is not an operating certificate. RDAP does not continuously test whether AS27747 is announcing every expected prefix. It does not measure delay, packet loss or congestion. It does not verify the condition of a generator, the charge of a battery bank or the water flow through a chiller. It does not certify the route taken by a customer connection.

This limit should not be read as criticism of LACNIC. A ledger becomes unreliable if it claims to know more than it records. A land registry can identify the recorded holder of a property without reporting whether the building's lifts worked this morning. In the same way, an internet registry can identify a resource holder without reporting whether every part of the holder's network is healthy.

The safest public statement is exact: LACNIC's record ties AS27747 to Telecentro S.A. Broader claims about current route visibility, physical ownership, security coverage or service quality require additional evidence gathered for those questions.

That precision also protects accountability. If registration data is wrong, the registry layer needs correction. If a route is missing, routing operations need investigation. If a physical circuit has failed, the transport layer needs repair. If a customer cannot reach support, the service process needs attention. Treating every problem as an ASN problem makes the real owner of the next action harder to identify.

What PeeringDB adds to the picture

PeeringDB is a widely used directory in which networks, exchanges and facilities publish interconnection information. A network profile can list its ASN, traffic range, peering policy, exchange ports and facility presence. The directory helps operators discover where direct interconnection may be possible and whom to contact.

The Telecentro profile makes several declarations visible. It identifies ASN 27747, gives the network type as cable, DSL and internet service provider, and describes a regional scope. It lists two AR-IX exchange connections with 100-gigabit port speeds and several facilities associated with the network. These details are far more useful for an interconnection engineer than a general marketing page.

For an ordinary reader, an exchange is a place or service where networks can connect and exchange traffic. Direct exchange can shorten paths, reduce dependence on paid transit and give operators more control. A network present at more than one facility may have more options than a network with only one declared point.

Options are not the same as proven resilience. Two exchange ports can depend on the same building, metro fibre, router platform or power system. Ports shown at different facilities can still share a long-haul segment. A port can be configured while carrying little traffic. A row marked operational can become stale after a change.

PeeringDB is maintained by participating organisations. That gives the data practical value: operators have reasons to keep interconnection information useful. It does not turn the directory into an independent live-measurement platform. Its traffic ranges, policies and facility records are declarations, not a continuous external audit.

The correct conclusion is therefore modest. PeeringDB supports the statement that Telecentro declares exchange and facility presence associated with AS27747. To establish current route use, an analyst would need fresh BGP observations. To establish physical diversity, a buyer would need route drawings, shared-risk analysis and tests. The directory points to likely places in the system; it does not reveal every dependency between them.

The Lomas del Mirador facility record

PeeringDB has a separate entry for Telecentro - Lomas del Mirador. The entry places the facility at Coronel Pringles 3407 in Lomas del Mirador, Buenos Aires, and links AS27747 to it. It lists 48-volt direct-current service. The field for diverse serving substations is shown as not disclosed.

The phrase not disclosed deserves careful reading. It is not evidence that the building has diverse substations. It is also not evidence that it lacks them. It means the public directory does not provide an answer. Any report that converts a blank or undisclosed field into a yes or no would be inventing a fact.

The address and network link are useful because they connect a declared physical facility to the public routing identity. They help explain why a company data-centre page and an ASN record belong in the same investigation. They still do not establish which racks host which systems, how much capacity is installed, whether every listed network connection is active or how the facility behaves during a failure.

PeeringDB also labels the organisation as the facility owner. Ownership in a directory is not a substitute for a legal property search, equipment inventory or contract review. A data-centre operator can own a facility while relying on utilities, fuel suppliers, maintenance contractors, fibre carriers and exchange services outside its direct control.

For customers, the facility entry should be used as a starting point. It makes a location and network identity legible. A buyer whose continuity depends on that site should ask for current, service-specific evidence: which power path feeds the contracted rack, where network handoffs enter, which components are shared and what happens when one component is deliberately taken out of service.

What Telecentro says is inside the data centre

Telecentro's current data-centre product page describes a substantial facility. The company says it has capacity for 600 racks and was designed following an adaptation of TIA-942 and local rules of Argentina's central bank. It presents a 99.995 percent service-level figure and says the site connects to major internet service providers and content delivery networks.

The power description is detailed. Telecentro says the site has access to four medium-voltage feeders, 2N standby generation using Cummins C3000 generators, 1,250-kilovolt-ampere uninterruptible power supplies in an N+1 arrangement, and lithium-ion battery banks in an N+1 arrangement.

The cooling description says cold and hot aisles are used, with front-to-rear airflow. The company lists N+1 computer-room air-conditioning units placed in separate rooms and chillers configured N+1. The page also says the building is divided into ten fire areas and physically separated into three modules.

For connectivity, the company describes a fibre-optic ring to four hubs, symmetric dedicated internet, links to major service and content providers, local-area-network services and copper or fibre cross-connections. These statements describe the architecture Telecentro markets to customers.

The source must remain visible in the wording. These are Telecentro's claims, not measurements made for this article. The page does not publish a current equipment inventory, commissioning report, load-test record, generator runtime test, fuel contract, maintenance log, cooling-capacity curve or fibre route drawing. It also does not say that the adaptation of TIA-942 is a certification. Describing it as certified would go beyond the page.

Company claims are not automatically weak. Operators know their systems and product pages can provide useful design detail. The accountability rule is that a claim should be attributed and matched to the evidence needed for the decision. A customer choosing a low-risk service may accept a design description. A hospital, bank or emergency operation may need test records, independent assurance and contractual remedies.

Four feeders do not automatically mean four independent supplies

The phrase four medium-voltage feeders sounds like four separate ways to receive utility power. It may represent valuable redundancy. The number alone does not reveal whether the feeders come from different substations, follow separate physical routes or share switching equipment upstream.

Imagine four extension cables plugged into one wall socket. There are four visible cables, but one failed socket removes all four. Real electrical systems are more complex, yet the principle is the same. Counting feeds at the building boundary is not enough to identify every common point of failure.

A serious diversity review would trace each feeder beyond the facility. It would identify the supplying substation, route, protection equipment and switching arrangement. It would ask whether planned maintenance on one section requires another section to be taken out of service. It would check whether flood, fire, civil works or utility control systems can affect several feeds together.

The PeeringDB facility page leaves diverse serving substations undisclosed. That public gap prevents an independent conclusion in either direction. Telecentro may hold detailed diagrams that are not public, and there can be good security reasons not to publish them. A customer who depends on the distinction can request evidence under an appropriate confidentiality arrangement.

Operational status matters too. A feeder can be designed, installed and energised but unavailable during maintenance. It can be available yet unable to support the intended load. A switching procedure can exist on paper but fail under unusual conditions. Capacity and availability have to be measured at the time and load that matter.

The public conclusion should therefore use the exact verb: Telecentro says the data centre has access to four medium-voltage feeders. The sources reviewed here do not independently establish four failure-independent utility paths.

What 2N and N+1 mean, and what they leave unanswered

Redundancy labels are shorthand for a design idea. If a system needs N units to carry its intended load, an N+1 arrangement adds one extra unit. A 2N arrangement aims to provide two complete sets of the required capacity. The labels are useful because they give engineers a common starting point.

Suppose a cooling system needs three units on a hot day. An N+1 design would provide four. In theory, one unit can be unavailable while three continue to meet the requirement. A 2N design would provide two complete three-unit paths or sets. In practice, the result depends on how the units are connected, controlled, maintained and supplied.

Installed quantity is only the first question. Each unit has a rated capacity under specified conditions. Actual usable capacity can fall with temperature, age, fouled filters, battery condition, fuel quality, control settings or maintenance. A shared switchboard, pipe, sensor or controller can defeat redundancy if it fails.

The label also does not reveal runtime. Batteries bridge a power interruption for a limited period. Generators need to start, accept load and continue running. Fuel must be available and safe to deliver. Cooling must remain stable during the transition. A generator arrangement described as 2N can still face common dependencies in fuel, controls, exhaust, maintenance or distribution.

Testing is what turns a design claim into operational evidence. Operators can simulate loss of a utility feed, remove a UPS module, start generators under load and observe temperatures while equipment is unavailable. Good tests record the conditions, expected result, actual result, alarms, recovery time and corrective actions.

Telecentro's page gives the public an outline: 2N standby generation, N+1 UPS and batteries, and N+1 cooling. It does not publish the test evidence needed to say how those systems performed under a specific failure. The careful conclusion is not that the redundancy fails. It is that the public page describes design topology rather than verified runtime performance.

Design capacity, installed capacity and usable capacity are different

Infrastructure descriptions often use one number as if it answered every capacity question. A data centre may be designed for a certain number of racks. Fewer racks may be physically installed. Fewer still may be available to new customers. Power or cooling can limit the load before floor space is full.

Telecentro says the facility has capacity for 600 racks. That statement does not specify how many racks were installed or occupied when the page was checked. It does not show the average or maximum power allocated per rack. It does not reveal how much capacity remains available in each module or which customer configurations can be supported.

The same distinction applies to network ports. A 100-gigabit exchange port is a nominal interface rate. It does not report average traffic, peak load, contracted capacity beyond the port, or spare capacity during a failure. Two 100-gigabit ports should not automatically be added together as 200 gigabits of resilient customer capacity.

Power systems have design, installed and usable values as well. Nameplate ratings are not the same as safe continuous output under local environmental conditions. Maintenance can remove modules. Reserve margins can be held for safety. Distribution limits can prevent all equipment from using the full nameplate total at once.

Status words matter. Announced means an operator has stated an intention or product. Designed means engineering plans specify a feature. Installed means equipment is physically present. Energised means power or service has been activated. Operational means it is in service. Available means it can be assigned or used. Tested means a defined procedure has produced observed results. These stages should not be collapsed.

The public sources support several of these statuses only at a high level. They show a current product description and directory entries marked operational. They do not provide a current asset-by-asset commissioning and capacity ledger. That is why the article avoids a single headline number for Telecentro's usable resilient capacity.

Cooling and fire separation need their own failure questions

Servers turn electricity into computation and heat. A data centre can retain utility and generator power yet still face service risk if cooling is lost. Computer-room air conditioners, chillers, pumps, valves, controls and water systems can each create dependencies.

Telecentro says its computer-room air-conditioning units are configured N+1 and placed in separate rooms. It also says the chillers are N+1. Separate rooms can reduce some shared physical risks, while an extra unit can provide capacity during maintenance or failure.

A full review would ask what remains shared. Do units rely on a common electrical board, pipe, control network or heat-rejection system? How quickly do room temperatures rise at the contracted load? Which alarms are generated? Can staff isolate a leak without taking down both paths? Is capacity sufficient during the hottest expected conditions with one unit unavailable?

Fire separation has similar layers. Ten fire areas and three physical modules can limit the spread of an event. The value depends on walls, doors, penetrations, detection, suppression, smoke control and operating procedures. Cables or pipes crossing boundaries can create shared routes. A public product page cannot establish the effectiveness of every barrier.

There is also a trade-off between disclosure and security. Detailed floor plans and equipment routes may be sensitive. Customers do not necessarily need a public blueprint. They do need enough assurance to understand which failures the design is intended to contain and how that claim was tested.

The right public language remains attributed and conditional. Telecentro describes separate cooling rooms, N+1 cooling and physical fire modules. Those features are relevant design controls. The sources reviewed here do not contain an independent current test of their performance.

A fibre ring to four hubs is not a route map

Telecentro's data-centre page says the facility uses a fibre-optic ring to four hubs. A ring can provide alternate directions: if one segment is cut, traffic may travel the other way. Connecting to several hubs can also create choices for transport and interconnection.

The word ring does not prove that every segment is physically separate. Fibre running in opposite logical directions can share one duct, bridge, tunnel, pole route or building entrance. A single excavation or fire can then affect both directions. Equipment at the hub can also be shared even when the cables are separate.

Capacity during a failure is another question. A ring may carry ordinary traffic comfortably while both directions are available. When one side fails, the remaining side must carry the diverted load. If the spare capacity is too small, the network may remain technically connected while customers experience congestion or selective loss.

Protection speed matters too. Some optical systems switch automatically within a short interval. IP routing can take longer depending on failure detection and policy. Existing customer sessions may be interrupted even when reachability returns. Monitoring may detect the cut immediately or only after users report symptoms.

A complete resilience claim would therefore need route drawings, shared-risk groups, normal and failure-state capacity, switching behaviour and test results. It would distinguish the data-centre ring from local access paths and from the public peering connections shown in PeeringDB.

The company page does not publish that evidence. It establishes that Telecentro markets a ring to four hubs as part of the facility's connectivity design. It does not establish that four fully independent civil routes exist or that every customer service can use all four hubs.

The 2025 ENACOM interconnection document answers a different question

Argentina's communications regulator published a 2025 document concerning an expansion of interconnection between Telecentro and Telecom Argentina. The first page says Telecom informed ENACOM that Telecentro requested an expansion and that Telecom accepted the request, making the requested technical resources available under the stated terms.

The signed table lists one new Session Initiation Protocol, or SIP, port at each of three points: Paraguay 927 in Rosario, General Alvear 66 in Cordoba and Ildefonso E. de las Muñecas 226 in Tucuman. The table gives the corresponding local area codes, says local numbering is involved and lists no co-location.

SIP is a signalling protocol commonly used to establish and manage internet-based voice sessions. A SIP interconnection port can be an important part of telephone service between operators. It is not the same as an internet exchange port, a customer broadband link or a complete backbone route.

The document also contains a condition for acceptance: the request is considered accepted when Telecom reports the availability of technical resources or issues the invoice for the new SIP port, whichever occurs first. That wording matters because it records a contractual process rather than a continuous live-status feed.

The three cities expand the public picture of inter-operator relationships, but they should not be plotted as proof of three independent IP-backbone routes. The document does not show which fibre carries signalling or media, whether the points share transport, how much spare capacity exists or what happens during a failure.

This is a common source error. A place name in an interconnection agreement can look like a topology map. The agreement proves that the parties documented specified interconnection resources. Physical diversity and current operational status require different evidence.

What one historical customer case can and cannot show

ENACOM's 2016 resolution concerns a complaint by one customer about telephone and internet service beginning on 2 March 2014. The resolution says Telecentro reported that the lines had been repaired and that refunds had been made. ENACOM's review found that the telephone lines remained out of service until 26 March, beyond the three-business-day repair period described in the applicable rule.

The regulator’s review concluded that the refund did not match the amount required under the applicable rules. The operative section imposed a fine equivalent to 400,000 units of assessment and ordered proof of the missing refund. It provided for a daily fine equivalent to 6,000 units if the refund order was not met after the stated period.

This is strong evidence about the regulator's finding in that case. It gives dates, the service involved, the company's stated response and the legal result. It shows why repair time and credit processes matter to service accountability.

It does not show that every Telecentro customer experienced a similar interruption. It does not identify the technical root cause. It does not connect the event to the Lomas del Mirador data centre, AS27747, an exchange port or a specific fibre path. It occurred more than a decade before this article was published.

A single case can reveal a possible failure mode: service can remain unavailable longer than a rule permits, and a refund process can become part of the harm. It cannot provide a network-wide failure rate. To measure current reliability, researchers would need a defined population, consistent outage data, time windows and a method that accounts for geography and service type.

The balanced conclusion preserves both sides. The case should not be hidden because it is old or individual. It should not be inflated into a claim that Telecentro's entire current network is unreliable. It belongs in the evidence ledger with its exact scope.

How a real failure can cross several layers

Consider a hypothetical power interruption near a data centre. The public registry for AS27747 can remain correct throughout the event. PeeringDB can continue to show exchange and facility entries. Neither record changes simply because utility power is lost.

Inside the facility, batteries may carry the load while generators start. Switchgear has to transfer power. Cooling equipment has to remain available. Network devices must retain configuration and sessions. If one component fails, an N+1 or 2N design may provide another path, but only if the supposedly separate path is healthy and not affected by the same cause.

Traffic also needs an external route. A data-centre room can remain powered while metro fibre is cut. A fibre ring may redirect traffic, provided the remaining segment has capacity and does not share the damaged civil route. Exchange ports can remain visible in a directory while sessions are down or traffic has moved elsewhere.

Customer impact depends on the service. A broadband user may lose access if a local aggregation site has no power even while the core is healthy. A hosted server may remain reachable through one carrier but not another. Telephone sessions may depend on an interconnection path that is different from ordinary internet traffic.

Recovery has stages. Engineers detect the event, identify the failed component, isolate it, switch or repair service, verify stability and later restore the preferred configuration. Moving traffic away from a fault is mitigation. Fixing the fault is repair. Returning to normal without creating a second interruption is restoration. A good incident report distinguishes all three.

This layered view explains why a network identity cannot be a resilience test. The identity anchors coordination. Resilience emerges from many physical and operational dependencies working together under stress.

What evidence would prove physical independence

A credible independence claim begins with route information. For power, that means feeder origins, substations, switchgear and shared utility dependencies. For fibre, it means building entrances, ducts, bridges, poles, metro segments and hub equipment. For cooling, it means electrical supplies, pipes, controls and heat rejection.

The next layer is capacity. Each surviving path must support the required load after a failure. A backup that carries only a fraction of normal demand may protect priority services while other customers are limited. That can be a valid design, but it should be described as partial continuity rather than full redundancy.

Then comes operation. Equipment needs current maintenance, alarms and trained staff. Spare parts and fuel must be available. Escalation routes should work outside office hours. Changes to one system should not quietly remove protection from another.

Finally, the design needs tests. A test should name the component removed, the expected traffic or power transition, the load, the observation points, the result and the recovery time. Failed tests are not necessarily signs of a bad operator; hiding or failing to correct them is more serious. A useful test programme finds weaknesses before an uncontrolled event does.

Some evidence can remain confidential. Public reporting does not require detailed maps that create security risk. Independent assessors, major customers and regulators can review sensitive material under controlled conditions. Public summaries can state the scope, date and outcome without exposing exploitable detail.

The current public sources do not contain this complete chain. They provide enough information to ask precise questions, but not enough to certify independence. That is an honest stopping point, not a negative verdict.

Questions customers can ask

A customer does not need to become an electrical or routing engineer. It needs to turn broad words into a short set of testable questions.

Start with identity. Ask for the exact legal company providing the service, the service name, the support route and any network numbers that matter. A brand, facility operator and contracting entity can be related without being interchangeable.

Ask where the service enters the building. If two links are offered, do they use different entrances, ducts, aggregation sites and carriers? Two invoices are not proof of two physical paths. Request a written description of shared risks.

Ask what the service-level figure measures. Is availability measured at the rack, the network port or an external destination? Which maintenance periods are excluded? How is an incident opened? What credit is available, and does the credit replace or merely accompany repair obligations?

Ask about power. Which equipment is covered by batteries and generators? How long can the design operate without utility power under the contracted load? When was the last loaded test? Does fuel delivery remain possible during a regional emergency?

Ask about cooling. What happens if one chiller or air-conditioning unit is unavailable on a hot day? Which temperature and humidity thresholds trigger action? Does the contracted area share cooling controls with another module?

Ask about connectivity. Which carriers and exchange paths can serve the contracted system? Does traffic switch automatically? How much capacity remains during a failure? Will public IP addresses, firewall rules, name resolution and active sessions continue to work on the alternate path?

Ask to see a recent test summary. The summary should state what was tested and whether corrective actions were closed. A certificate or design label can support assurance, but it should not replace evidence that the current operating configuration was exercised.

Record responsibilities. The facility, network operator, customer, utility, carrier and equipment vendor may each own part of the response. A contact matrix and a simple dependency diagram can prevent hours of confusion during an incident.

How journalists and researchers should describe the evidence

Precise verbs protect readers. LACNIC records AS27747 to Telecentro S.A. PeeringDB lists or shows declared connections. Telecentro says its facility has specified design features. ENACOM documented an interconnection request and issued a historical resolution. These verbs identify the source and avoid implying independent observation.

Registered to is not the same as physically owned by. Connected at is not the same as carrying all traffic through. Designed for is not the same as installed. Installed is not the same as available. Available is not the same as tested. A service-level promise is not the same as measured historical performance.

Time should be explicit. Network directories and product pages change. A report should record when the information was checked. A current decision should refresh the record rather than relying on an old screenshot.

Negative findings should also be bounded. If a public field says that diverse substations are not disclosed, write that the information is not disclosed. Do not conclude that no diversity exists. If no public route map is found, do not conclude that the operator has no route map.

Historical enforcement needs proportion. State the customer, date range, service and finding available in the document. Avoid turning one case into a percentage or a statement about every customer. If a pattern is claimed, define the dataset used to establish the pattern.

Finally, separate advocacy from observation. This article does not argue that one ownership model or regulatory structure automatically produces resilience. It asks whether the public evidence supports specific infrastructure claims. The running system, not a preferred narrative, is the final test.

Who is affected

Residential customers are affected because a provider's public network identity eventually supports everyday connections for work, education, banking and communication. They benefit from accurate records when operators need to coordinate, but their actual experience depends on local access, power and repair.

Small businesses are affected because connectivity loss can stop card payments, cloud applications and customer support. They need site-specific evidence about access paths and backup, not only a provider's general ASN or data-centre description.

Data-centre customers are affected because rack space, power, cooling and network connectivity form one service chain. A weakness in any link can interrupt the hosted system. Buyers should understand which parts are dedicated, shared and externally supplied.

Other networks are affected because LACNIC and PeeringDB records support routing and interconnection coordination. Accurate contacts and current declarations reduce the time needed to resolve problems.

Utilities, fibre carriers, equipment vendors and maintenance providers are affected because Telecentro's resilience depends partly on services beyond the company boundary. Outsourcing or leasing is normal; responsibility still needs to be mapped.

Regulators are affected because service rules, interconnection agreements and enforcement records operate at different layers. A regulator can document a customer case or contractual point without thereby measuring the complete IP network.

Researchers and journalists are affected because public infrastructure databases make quick conclusions tempting. Using each source only for the facts it can support produces slower headlines and stronger reporting.

Telecentro is affected because accurate boundaries prevent both exaggerated praise and unsupported blame. Design features should receive credit as design features. A historical case should remain a historical case. Current operating performance should be judged with current evidence.

What the public sources still do not tell us

The sources do not provide a complete current list of prefixes originated by AS27747 or a multi-vantage view of live BGP paths. The registry identifies the ASN, while a routing study would need observations taken at a stated time.

They do not establish the current Route Origin Authorization status of every related prefix. RPKI can help networks check whether an ASN is authorised to originate a prefix, but a registry page alone does not provide a company-wide security verdict.

They do not publish the data centre's full electrical single-line diagram, feeder route, generator load test, fuel autonomy, battery runtime or current maintenance state. The company page describes topology and product features rather than a complete assurance record.

They do not publish a civil-route map for the fibre ring or measured spare capacity after the loss of a segment. They do not show whether all customers can use every hub or exchange connection.

They do not connect the 2025 SIP ports to Telecentro's IP routing topology. Voice interconnection and internet routing can share transport, but the document does not establish that relationship.

They do not identify the technical cause of the 2014 customer interruption or connect it to a named facility. They do not provide a current network-wide outage rate, repair-time distribution or customer sample.

They do not settle the legal ownership of every rack, cable, generator, utility connection or exchange port. Operators commonly combine owned and leased assets. The important questions are control, responsibility, dependency and tested continuity.

These gaps do not make the public sources useless. They define the line between evidence and assumption. The records are strong enough to establish network identity, declared presence, company claims and specific regulatory events. They are not strong enough to certify resilience.

What to watch next

The first item is route visibility. A future assessment could record the prefixes observed with origin AS27747 from several collectors, the path changes seen and the exact observation time. It should avoid treating one collector as a complete view.

The second is PeeringDB freshness. Exchange and facility entries can change as ports move or capacity is upgraded. Operators making interconnection decisions should confirm current details with the relevant network or exchange.

The third is power-diversity evidence. A public or independently reviewed summary could clarify whether utility feeds have different substations and routes, without exposing security-sensitive detail. Loaded transfer-test results would add stronger operational evidence.

The fourth is usable failure-state capacity. Customers need to know which loads remain supported when one power, cooling or network component is unavailable. Nameplate totals should be separated from committed and spare capacity.

The fifth is fibre shared risk. A ring becomes more meaningful when route diversity, building entrances and failure-state capacity are documented. Regular controlled tests can show whether traffic moves as designed.

The sixth is incident reporting. A useful report distinguishes detection, mitigation, repair and restoration. It names the affected service and geography and explains corrective action without exposing sensitive configuration.

The seventh is customer-level evidence. Service availability, repair time and credits should be evaluated with defined data rather than isolated praise or complaints. Historical cases can inform questions, while current conclusions need current samples.

The final item is language. Registered, declared, designed, installed, energised, operational, available and tested should remain different states. Clear status words make infrastructure reporting far more useful.

How to read evidence during an outage

An outage is when people most often collapse every layer into one explanation. A website stops loading and the phrase the network is down spreads quickly. That phrase may describe the experience, but it does not identify the failed component.

Begin with time, place and scope. Record when the problem began, where the user was and which services failed. Check whether other destinations remain reachable. A voice failure with working web access suggests a different path from a complete loss of service.

Keep registration separate from reachability. LACNIC's RDAP service may continue to return the correct AS27747 record throughout an outage. That means the ledger is functioning; it does not mean customer traffic is moving. An unchanged PeeringDB page likewise does not prove a live session.

Fresh routing observations can narrow the question. If expected prefixes disappear from several viewpoints, routing becomes a stronger lead. If routes remain visible, local access, internal transport, DNS, congestion or the destination may still be at fault. A visible route does not guarantee delivery to every customer.

Facility alarms and customer telemetry add other layers. Power events, generator starts, temperature changes, optical alarms, interface errors and support-ticket times can show how the purchased design behaved. A backup path that becomes reachable but cannot carry required applications is only a partial recovery.

Status updates should distinguish investigation, mitigation and restoration. Moving traffic is not the same as repairing the cause. Restoring the preferred configuration can itself create risk and should be verified.

After the event, compare the evidence with the design claim. Did an N+1 component support the load? Did the fibre ring switch? Were customer sessions preserved? Did communications and credits follow the contract? This is how resilience becomes observable rather than assumed.

The reality behind AS27747

AS27747 is a valuable public identifier. LACNIC's ledger connects it to Telecentro S.A. PeeringDB shows the network's declared interconnection and facility presence. Telecentro's page describes a data-centre design, while ENACOM records particular interconnection and enforcement events.

The records work best when their boundaries remain intact. The ASN identifies a routing domain. A facility directory records declared presence. A company page states a design. A contract records obligations. A ruling records a finding in a case. None becomes a complete resilience test merely because it is public.

Operational reality sits underneath all of them. Routes must carry traffic. Fibre must remain intact or switch to a healthy path. Power must transfer. Batteries and generators must support the load. Cooling must keep temperatures within limits. Staff must detect faults, communicate and restore service.

This does not put records and operations in conflict. The internet needs accurate ledgers so networks can coordinate. Customers need clear contracts so responsibility is visible. Engineers need tests and telemetry so designs can be trusted. Regulators need scoped evidence so findings remain fair.

For a non-specialist, the conclusion can remain straightforward. Use AS27747 to identify Telecentro's public network. Use PeeringDB to understand declared interconnection. Use the company page to understand what Telecentro says it built. Use current measurements, route evidence, capacity records and failure tests to decide how resilient the service actually is.

Sources