TELCOBRAS Pitches Cali Telemetry and Hybrid Cloud, but AS262929 Shows One Upstream

Summary

• TELCOBRAS publicly offers dedicated and broadband fibre connectivity, hybrid cloud and telemetry projects, but its pages disclose no current route map, facility list, throughput, service-level commitment, backup-power duration or recovery design.
• On 17 July 2026, public routing observations showed AS262929 originating 191.102.61.0/24 and 191.102.62.0/24 with valid route-origin authorisations, no visible IPv6 and one observed upstream, AS262191 Liberty Networks de Colombia.
• Two originated /24s establish an active Internet presence, not two physical exits; customers and public authorities still need proof of diverse access paths, independent handoffs, powered cloud capacity, field spares and tested restoration procedures.

A streetlight sensor is only the first link

Imagine a roadside cabinet in Santiago de Cali at the hottest point of the afternoon. A technician opens it beside a row of public lights. Inside, a controller receives readings from a meter or sensor. A low-power radio carries a message to a LoRaWAN gateway. That gateway needs electricity, an antenna, a working local link and a route toward the application that interprets the reading. The application, in turn, needs compute, storage, authentication and an alert channel. If any one of those dependencies fails, the lamp may continue to shine while the remote view goes dark.

The public sees a smart-lighting project; the operator has to manage a chain of ordinary physical obligations.

That chain is the right opening for TELCOBRAS because the company’s home page places several propositions beside one another: connectivity, a customer’s “own hybrid cloud,” collaboration and information security. The same page says it installed LoRaWAN sensors for energy management in Cali public lighting, meteorological stations integrated by telemetry for an early-warning system in Risaralda, controls and sensors for water-treatment plants in Cali, and public Wi-Fi zones in rural town centres. These are statements by the company about its portfolio. The page gives no commissioning dates, contract identifiers, quantities, customer acceptance documents, site coordinates or current operating statistics, so it cannot by itself establish that every described asset remains installed or in TELCOBRAS’s care.

The distinction becomes clearer on the company’s projects page. It lists the same telemetry and access activities and adds rural-school Wi-Fi installations, but still does not allocate responsibility among TELCOBRAS, a customer, a field subcontractor, a radio-network operator or a cloud host. A project integrator can design and install equipment without owning the pole, the feeder circuit, the access fibre or the servers that ultimately receive the data. It may remain the maintainer, hand maintenance to the customer, or depend on several other providers. Each arrangement creates a different recovery path.

TELCOBRAS provides more detail for its risk-monitoring project. That page says sensors and meteorological stations were installed at strategic points along rivers and streams in Risaralda, that readings were collected in real time, and that anomalous patterns could trigger text messages and other alerts. It is a useful description of the intended mechanism. It is not an inventory: it does not name the municipality precisely, enumerate stations, identify the communications bearer, state who powers the sites, disclose the receiving facility or report uptime. The claimed social result therefore rests on a technical chain whose individual links are not visible in the public material.

Those gaps matter more in public-service telemetry than in a disposable consumer application. When a weather station loses power or a gateway loses backhaul, the absence of data can look like the absence of danger. When a water-treatment controller cannot reach its supervisory service, staff may lose timely visibility into a process that still continues physically. When a public-lighting node cannot report energy or fault data, maintenance crews may have to fall back to inspection and citizen reports.

No single outage necessarily creates immediate harm, but the architecture changes how quickly authorities can detect and respond to a developing problem.

The same logic reaches commercial users. A company buying dedicated Internet and hybrid cloud is not buying two unrelated labels. Its branch access, authentication, applications, backups and remote work can converge on the same fibre entrance, router, upstream session, rack or support team. TELCOBRAS’s portfolio may allow one provider to coordinate more of that chain. Coordination is valuable, but concentration is also a failure domain. The core question is not whether the services exist as offers. It is which physical and organisational dependencies are shared, and which remain available when the first path fails.

The legal company is visible; the operating perimeter is not

The public number-resource record gives TELCOBRAS a durable identity. LACNIC’s RDAP record for AS262929 names TELCOBRAS SAS ESP as the registrant, dates the autonomous-system registration to March 2014 and links the resource to a Cali-based organisation contact. A separate 2025 LACNIC electoral register includes TELCOBRAS SAS ESP among Colombian organisations. These records support the narrow conclusion that the company is a recognised holder of Internet number resources in the LACNIC region. They do not identify shareholders, fibre title, cloud-rack leases or project-maintenance obligations.

Commercial records help align the legal name but also show why an address must not be mistaken for a network site. A Colombian company-directory entry associates NIT 900281488-1 with a simplified joint-stock company incorporated in Cali in April 2009 and describes wired telecommunications as its principal activity. TELCOBRAS’s own contact page gives Avenida 2 Norte #3N-108 in Santiago de Cali. The LACNIC organisation record gives another Cali address, while the commercial directory gives Carrera 83A #20-20. Those entries may reflect different dates, offices or contact functions. None is labelled as a point of presence, network-operations centre or data hall.

The company’s about page describes an integrator working with organisations on policy, strategy and technology adoption rather than a pure retail access provider. Its LinkedIn company page says it has more than 20 years of experience and highlights wireless networks, fibre, cloud and large technology projects. That experience claim may encompass work by founders, teams or predecessor activity before the 2009 incorporation date. It should not be used to move the company’s legal formation backwards without a supporting corporate record.

The word “ESP” in the public name also deserves discipline. It is part of the registered resource-holder label and commonly signals a public-service enterprise in Colombia, but the available pages do not set out a current corporate charter or ownership structure. The evidence here supports a Cali telecommunications company with a registered ASN and a history of sector reporting. It does not support calling TELCOBRAS state-owned, assigning it an unverified parent, or treating every public-sector project on its website as an asset owned by the company.

The operating perimeter becomes even less certain once service delivery begins. A dedicated link can use TELCOBRAS-owned fibre, leased fibre, another carrier’s Ethernet service, radio backhaul or a mixture of these. A “hybrid cloud” can combine customer-owned equipment with leased rack space and third-party compute. A telemetry project can leave field equipment with the contracting authority while TELCOBRAS supports communications or software. The legal entity that signs a contract may therefore control customer support and integration without owning every failure-prone asset underneath.

This is not merely an accounting distinction. During an outage, the operating perimeter determines who can enter a site, dispatch a crew, authorise a splice, replace a power supply, change a route, restore a virtual machine or notify the customer. Resilience depends on responsibility being explicit before the incident. A useful service schedule would name the contracting entity, every material subcontracted segment, the handoff points, the fault-responsible party and the escalation sequence. Public evidence currently identifies TELCOBRAS as the company and AS262929 as its routing identity; it does not publish that responsibility map.

The offer joins fibre, cloud and integration

TELCOBRAS’s services page divides the offer into connectivity, cloud, collaboration and information security. It says dedicated and broadband Internet are supported by a fibre network. It presents hybrid cloud as a way for customers to reach data and applications from anywhere, with availability, accessibility, flexibility and support. It also describes customised collaboration networks and protection of customer information. This is a coherent enterprise proposition: connect the customer, host or integrate its workload, secure it and support its users.

The physical content of that proposition is more demanding than the page suggests. Dedicated Internet needs an access circuit, an edge device, an upstream path and enough committed capacity under fault conditions. Broadband fibre needs optical distribution, splitters or active Ethernet equipment, customer terminals and field repair. Hybrid cloud needs at least one powered equipment location, compute, storage, switching, cooling, backup and a way to recover data. Collaboration depends on name resolution, identity, voice or messaging services and endpoint support.

Security depends not only on software controls but on the availability and integrity of all the infrastructure carrying the protected traffic.

A historical public contract record shows that TELCOBRAS has operated in a multi-party service context. The Empresa de Recursos Tecnológicos’ 2017 contract schedule lists TELCOBRAS for local and national telecommunications including last-mile data links, voice, Internet, television, data-centre and cloud services, expressly using the networks, technology and services of the parties in a complementary way. That is strong evidence of a past commercial relationship and of a service boundary that could include shared infrastructure. It is not evidence that the same agreement, routes or suppliers remain active in 2026.

Regulatory history confirms that TELCOBRAS has reported dedicated-Internet activity, but the dated figures must not be read as present capacity. A Ministry TIC fourth-quarter 2014 sector bulletin says TELCOBRAS filed dedicated-access information late for the third quarter of 2014. A Ministry sector-statistics view for Valle del Cauca shows three dedicated-Internet subscribers for TELCOBRAS at the 2016 fourth-quarter cutoff. The Communications Regulation Commission’s 2017 fixed-data market review likewise places TELCOBRAS at the very small end of the historical subscriber distribution.

Those old counts prove neither contraction nor current scale. Dedicated enterprise circuits can carry material revenue with few customer records, reporting definitions can change, and a project integrator may earn income outside fixed-Internet subscriptions. The evidence simply prevents a leap from a broad service menu to a large retail base. There is no current public count of active circuits, project sites, cloud tenants, racks, support personnel or recurring revenue in the reviewed material.

The economic attraction of integration is nevertheless clear. A smaller enterprise or public authority may prefer one accountable supplier for access, hosting, telemetry and support. TELCOBRAS can potentially earn margin across several layers and solve coordination problems that customers do not want to manage. Yet the same breadth raises the burden of proof. If a single upstream, rack, fibre entrance or small support team sits under several products, a failure can affect more than Internet access. It can also interrupt remote applications, monitoring and the channels used to diagnose the original fault.

The most useful interpretation of the offer is therefore conditional. TELCOBRAS appears to be an enterprise connectivity and technology integrator with its own public ASN and address space. It markets fibre-backed access and hybrid cloud and showcases public-service technology projects. What remains undisclosed is which elements it owns, which it leases, how much is installed, how much is usable, and how the combined service behaves after a shared dependency fails.

AS262929 is small, active and unusually legible

The public routing footprint is compact enough to describe without confusing it with the whole company. LACNIC’s address record for 191.102.60.0/22 allocates the block from 191.102.60.0 through 191.102.63.255 to TELCOBRAS SAS ESP. A /22 contains 1,024 IPv4 addresses in total. Registration means the organisation holds the number resource; it does not mean all addresses are assigned to customers, reachable, powered or carrying production traffic.

At the July 17, 2026 observation point, RIPEstat’s AS overview identified AS262929 as announced and associated it with TELCOBRAS. Its announced-prefixes view showed two routes: 191.102.61.0/24 and 191.102.62.0/24. Together, two /24s contain 512 IPv4 addresses, half of the registered /22’s address count. That arithmetic says nothing about bandwidth. One address can front a busy shared service; many addresses can sit idle.

RIPEstat’s routing-status view provided three further observations. It showed both active IPv4 prefixes, no announced IPv6 space and one observed neighbour. It also reported full visibility for the IPv4 routes across the RIPE RIS peers counted at that moment. Full collector visibility means the routes were broadly seen in that observation system. It does not mean every destination could reach every host, that latency was low, or that the underlying access and transit had a service guarantee.

Route-origin security is one of the stronger parts of the public record. RIPEstat reported the 191.102.61.0/24 origin as RPKI-valid for AS262929, with a maximum length of /24. It gave the same valid result for 191.102.62.0/24. Valid route-origin authorisation helps networks reject some accidental or unauthorised origin announcements. It does not protect against a fibre cut, an upstream outage, a router failure, congestion, power loss or a correctly originated but unreachable service.

Independent routing views agree on the small footprint. Hurricane Electric’s AS262929 page lists the two originated /24s and one IPv4 relationship with AS262191. Its individual pages for 191.102.61.0/24 and 191.102.62.0/24 associate both routes with TELCOBRAS and the larger LACNIC allocation. bgp.tools’ AS262929 view likewise reports two IPv4 prefixes, no IPv6 prefixes and AS262191 as the upstream. IPGeolocation’s ASN view offers another public snapshot of the same registered network identity, though geolocation and derived network classifications should be treated as secondary observations rather than facility evidence.

Agreement among route collectors and registries is valuable because each view has limits. LACNIC establishes registration. RIPE RIS observes routing from a set of peers. Hurricane Electric and bgp.tools derive relationships from public routing information. None sees a private cross-connect, an unused backup circuit, a customer virtual network or a dark fibre reserved for restoration. Conversely, a second contract or cable that never carries a public route will not appear in the AS relationship count.

The visible result is nonetheless operationally meaningful. AS262929 was active on the publication date. It originated two route-secured IPv4 prefixes. It exposed no public IPv6 route. And the public path evidence converged on one neighbouring upstream. That is a much firmer statement than saying TELCOBRAS has no redundancy. The records reveal one public exit relationship; they leave physical, private and standby alternatives unproven.

One upstream is a concentration signal, not a complete topology

RIPEstat’s ASN-neighbours result showed one unique neighbour for AS262929 on July 16, 2026: AS262191. The direction recorded by the service is consistent with AS262191 sitting upstream of TELCOBRAS. Public route views therefore suggest that both originated /24s reached the wider Internet through the same autonomous system at the observation point. That is the factual basis for the article’s concentration question.

LACNIC’s registration for AS262191 identifies the neighbouring network as LIBERTY NETWORKS DE COLOMBIA S.A.S. Liberty’s own April 2025 Colombia expansion announcement says it operated in 16 Colombian cities over more than 9,000 kilometres of metropolitan fibre and had activated new points of presence in Bogotá, Medellín and Cali. It also describes two Colombian data centres and regional network, security and customer-support operations. These are operator claims about Liberty’s footprint. They make a Cali handoff plausible, but they do not reveal where or how TELCOBRAS interconnects.

An upstream with a large network can deliver diverse routes inside its own domain. TELCOBRAS could also buy two ports, enter two facilities or use physically separated local tails while presenting the same AS neighbour in BGP. If so, losing one port or access span might not remove the route. The inverse is equally possible: two logical sessions could share the same building entrance, duct, pole line, optical shelf, power supply or Liberty aggregation point. BGP would not resolve that physical difference.

The absence of a public peering profile adds uncertainty rather than a verdict. A query to the PeeringDB network endpoint for ASN 262929 returned no network record at the research cutoff. PeeringDB participation is voluntary, so an empty result does not establish that TELCOBRAS lacks exchange or private interconnection. It means there is no public entry there from which a buyer can verify facilities, exchange memberships, port speeds or an open peering policy.

Colombia’s regulator provides useful historical context. The CRC’s 2016 study of efficient Internet traffic exchange listed both AS262929 and AS262191 among Colombian autonomous systems. That document shows that the two network identities were already part of the national routing landscape, but it is not a present-day relationship map. The current single-neighbour observation comes from route data, not from the decade-old list.

For an enterprise buying Internet, the practical issue is the failure set. If Liberty withdraws TELCOBRAS’s routes, if the sole visible handoff loses power, or if the local fibre to that handoff is cut, both /24s may become unreachable together. If only one TELCOBRAS edge router fails but a second independent edge remains, service may continue even though both routes still show the same upstream. If Liberty has a regional incident beyond the handoff, physical access diversity may not help.

Each scenario requires a different control: local path separation, dual edge equipment, upstream diversity, independent power, or a tested alternate service.

The term “single upstream” should therefore be used precisely. It describes what public routing observations expose, not every circuit in the company’s inventory. It is a reason to request evidence, not permission to invent an outage history. The missing proof is concrete: circuit identifiers, A- and B-end facilities, carrier letters, route drawings, shared-risk groups, edge-router separation, power feeds, failover policy and a recent test showing traffic survives the loss of the primary handoff.

Two /24s do not create two physical exits

Two public prefixes can be useful for address management. TELCOBRAS can place services, customer assignments or infrastructure in separate /24s. It can apply different routing policy, move traffic between equipment or limit the blast radius of an addressing mistake. The two valid route-origin authorisations also make the intended origin explicit. None of that requires the packets to leave Cali over different fibre.

The simplest topology consistent with the public evidence is one edge router announcing both /24s to one Liberty port. A somewhat stronger design would use two TELCOBRAS routers connected to two ports on one Liberty device. A stronger design again would use two routers, two local fibre routes and two Liberty points of presence. All three can appear to outside collectors as the same two prefixes and the same one neighbour. The logical view cannot choose among them.

Address count is especially easy to confuse with service capacity. The registered /22 represents 1,024 IPv4 addresses, and the two currently announced /24s represent 512. Those are namespace quantities. They do not disclose a 1-gigabit, 10-gigabit or 100-gigabit port; they do not state committed information rate, oversubscription, latency, packet loss or headroom. The number of addresses still reachable during a failure may be 512, zero or something in between, depending on where the fault sits.

The unannounced portions of the /22 add no automatic standby bandwidth. They may be held for future use, used in a way not visible as separate routes, filtered, or simply idle. Announcing another /24 through the same upstream would increase visible address space without removing the shared dependency. Conversely, a backup service using provider-assigned addresses might provide real resilience while remaining invisible under AS262929 until activated. This is why an audit must follow circuits and paths rather than count prefixes.

For TELCOBRAS’s enterprise proposition, usable capacity should be measured under both normal and failed conditions. A primary circuit may deliver its contracted rate while the backup is much smaller. A second path may exist but require manual activation, address changes or a visit to the customer site. A cloud workload may be reachable through a backup Internet path while its storage or authentication remains in the failed location. Capacity exists for continuity only when the complete customer service can operate through it at an agreed minimum performance.

The public evidence contains no port speeds, committed rates, traffic charts, utilisation percentiles or restoration exercises. It also contains no statement that the two /24s terminate on different routers or that the company buys transit in two facilities. The defensible conclusion is therefore limited but important: two active routes prove an addressable network; they do not prove path diversity. In a continuity decision, the burden shifts from the buyer counting prefixes to the supplier demonstrating independent failure domains.

Hybrid cloud begins in a powered room

“Hybrid cloud” describes an allocation of workloads across customer-controlled and externally hosted resources. It does not remove hardware. Somewhere, a processor runs the application, a storage device holds data, a switch forwards packets and a power system keeps them alive. TELCOBRAS’s service page promises availability, accessibility, flexibility and support, but it does not name a facility, cloud partner, jurisdiction, rack footprint, certification, backup method or service-level target.

That absence leaves several plausible operating arrangements. TELCOBRAS might operate equipment in its own room, lease racks in a Colombian data centre, resell capacity from a larger platform, manage servers on a customer site, or combine all of these. Each can legitimately support a hybrid service. Each also places control and recovery somewhere different. A customer cannot infer where its data sits or who replaces failed hardware from the word “cloud.”

Power is the first hidden capacity constraint. A rack can be physically installed yet unusable if its feed is unavailable, its breaker limit is reached, cooling cannot support the load or the backup generator has insufficient autonomy. A server can be powered but unavailable because a switch, firewall or storage array failed. A backup can exist but fail recovery because it shares credentials, a network path or the same room. Installed capacity becomes usable only when power, cooling, network, hardware, software and operating staff are all available together.

Connectivity can create another shared point. If remote users reach a TELCOBRAS-managed environment through the same visible upstream that carries ordinary Internet access, an AS262191 incident could affect both the customer’s branch connection and its path to the hosted workload. A separate cloud provider may still be healthy, but users behind the failed access cannot reach it. A backup access carrier may restore reachability, yet an application tied to TELCOBRAS addresses or filtering may still need changes.

The relevant test is end-to-end, from a user location to the recovered application, not whether an isolated server answers inside a room.

Recovery promises should therefore separate data protection from service continuity. Backups protect data if they are complete, immutable enough for the threat, geographically appropriate and regularly restored. High availability keeps a service running through component failures. Disaster recovery rebuilds service after a larger loss. These capabilities can overlap but are not synonyms. The reviewed public material does not quantify recovery-point or recovery-time objectives, replication lag, backup retention, failover location or the staff authorised to declare a disaster.

There is an economic reason for the opacity: small integrators often assemble solutions from customer requirements rather than publish a standard platform. A bespoke arrangement can be more suitable than a rigid catalogue. It can also make comparative buying difficult. The customer should require a bill of materials and responsibilities for its own service even if TELCOBRAS does not publish a universal facility list. The document should identify installed, powered and licensed capacity; what is reserved for that customer; what is shared; and what remains usable during the loss of each named component.

The hybrid-cloud claim is thus credible as a service category but unmeasured as infrastructure. Public evidence shows that TELCOBRAS markets and has historically contracted for cloud-related services. It does not establish where current workloads run or how they fail over. Until those details are produced for a specific engagement, cloud resilience cannot be added to network resilience as though two unknowns made one certainty.

Telemetry multiplies the failure surface

A LoRaWAN field device is designed to send small amounts of data over long range with modest power consumption. That can make it well suited to public lighting, environmental sensors and remote monitoring. It does not make the full service independent of power or backhaul. A sensor may have a battery while its gateway depends on mains power. The radio hop may work while the gateway’s fibre or mobile link is down. The data may reach the application while the notification service fails.

TELCOBRAS’s project descriptions expose at least three different public-service contexts. Street-lighting telemetry in Cali concerns energy management and potentially fault visibility. Water-treatment automation concerns sensors and controls for water variables. Risk monitoring in Risaralda concerns hydrological or weather information and alerts. Their technical components overlap, but their consequence and safe fallback differ. A lighting node can often tolerate delayed reporting. A water process may require local control to continue safely without remote communications.

An early-warning system must distinguish a silent sensor from a safe river.

The field layer therefore needs its own resilience. Site power may require a battery sized for the expected outage and periodically tested. Enclosures must resist weather, heat, moisture, insects, theft and accidental damage. Antennas and cables need surge protection and correct grounding. Sensors drift and require calibration. A gateway may need local buffering so readings are not lost during a backhaul interruption. None of these controls can be inferred from a photograph or a project name.

The communications layer has different questions. How many gateways can hear each sensor? Do gateways use TELCOBRAS fibre, another carrier, mobile service or several bearers? Does a local network server continue operating if the Internet path fails? Are messages deduplicated when several gateways receive them? Can a technician remotely diagnose a site whose backhaul is already down? The company’s public pages do not disclose the gateway count, coverage method, carrier mix or failover design for the showcased projects.

The application layer adds compute, storage and operational response. A telemetry message only creates value if it is timestamped, validated, retained and presented to someone able to act. Alarm thresholds must be maintained. Contact lists must remain current. Text-message delivery depends on another communications service. If the hosted environment sits behind the same route concentration as ordinary support access, staff may lose both the data view and the easiest path to administer it. Local procedures are essential when the remote service is unavailable.

Maintenance labour ties the layers together. A field crew needs the right spare sensor, gateway, optical transceiver, power supply or antenna, plus safe access and authority to work on public infrastructure. A network engineer needs telemetry from routers and a way to reach the alternate path. A cloud engineer needs clean backups and current recovery instructions. A support desk needs to tell customers which layer failed and what remains available. Concentrating expertise in a small team may be efficient in normal operation but can lengthen simultaneous recovery tasks.

The affected people are also different at each layer. Enterprise staff lose applications or branch connectivity. Public-lighting teams lose remote energy and fault information. Water-service personnel may lose supervisory visibility. Emergency managers may lose environmental observations or alert automation. Residents may never know TELCOBRAS’s name, yet depend indirectly on a project the company says it helped install. That indirect dependency is why project acceptance should include not only initial function but maintenance ownership, spare stocks, data continuity and repeated failover tests.

Failure and recovery run from the roadside to the upstream

The strongest way to evaluate TELCOBRAS is to walk a fault from edge to core. Start with site power. A telemetry station loses mains electricity during severe weather. If it has a healthy battery, it continues measuring. If the gateway has separate backup, messages continue leaving. If only the sensor is backed up, readings may accumulate locally or disappear. Recovery requires a known autonomy, battery-health checks, a low-power alarm and a field-replacement plan.

Move to the local radio and gateway. Interference, antenna damage, a failed gateway or a configuration error can interrupt an area while the wider Internet remains healthy. Coverage from a second gateway could protect some nodes, but only a radio survey and received-message data can demonstrate it. A technician needs a way to distinguish loss of the sensor from loss of the gateway. Replacement hardware must carry compatible credentials without creating an unsafe shortcut.

Next comes access transport. A fibre cut, damaged pole, failed splice or powered access switch can isolate the gateway, customer branch or cloud handoff. A second upstream AS is irrelevant if both circuits share that access segment. Recovery may require an alternate fibre entrance, a radio or mobile bearer, or a field splice. The service commitment should define who owns the damaged segment and when the restoration clock begins, especially where a third party controls poles, ducts or a building entrance.

At the TELCOBRAS edge, a router, optical module, cross-connect or configuration can fail. Dual equipment helps only if control, power and cabling are sufficiently separate. A spare router in a box is installed inventory but not immediate capacity. A second live router sharing one power strip or one upstream port is still exposed. Evidence should include device roles, power feeds, connection endpoints and the last successful controlled failover.

Then comes the visible upstream. If AS262191 stops carrying both TELCOBRAS prefixes, outside reachability can disappear even while TELCOBRAS’s local network is intact. A second physical circuit to the same upstream may protect against a local tail failure but not every Liberty incident. A separate upstream could reduce that dependency, provided its route and facility are truly independent and TELCOBRAS can announce or translate customer services through it. A standby link that has never carried the production service is a recovery hypothesis, not demonstrated usable capacity.

The cloud or rack layer can fail independently. A breaker trip, cooling alarm, storage problem, hypervisor fault, security event or erroneous change may leave the routes visible while applications are unavailable. Recovery may move workloads to another host, restore from backup or replace hardware. The customer experience depends on dependencies such as identity, domain resolution and firewall policy moving with the workload. A network-only availability measure would miss this failure entirely.

Finally, human coordination can turn a contained fault into a long interruption. The support desk must classify the layer, contact the right owner, preserve evidence and keep affected users informed. Field and network staff may face concurrent incidents if weather causes both power and fibre damage. Public-service clients need a manual operating state while restoration proceeds. A credible recovery plan names decision makers, suppliers, spares, access permissions and communication channels that do not all depend on the failed service.

This sequence shows why there is no single “redundant” checkbox. Resilience is the minimum surviving performance across the complete service. A sensor can have two batteries and one gateway. A gateway can have two radio paths and one fibre. A network can have two routers and one upstream. A cloud can have two servers and one power domain. Each layer needs an explicit failure condition, a required remaining service level and evidence that recovery works within an agreed time.

The public record is richer on identity than on usable capacity

Public evidence tells a consistent story about identity. TELCOBRAS is a Cali company associated with NIT 900281488, appears in LACNIC records, holds AS262929 and an allocated IPv4 /22, and has reported telecommunications activity to Colombian authorities. The same evidence is sparse on current commercial scale. No reviewed page states present revenue, active circuit count, contracted bandwidth, rack power, server count, cloud utilisation, telemetry-node count or on-call staffing.

The historical figures illustrate the danger of filling that gap with whatever number is available. Three dedicated-Internet subscribers in Valle del Cauca at the end of 2016 cannot be projected into 2026. Two announced /24s cannot be converted into 512 customers. A registered /22 cannot be converted into network throughput. Liberty’s 9,000-kilometre Colombian metropolitan claim cannot be added to TELCOBRAS’s footprint. Each number measures a different thing, at a different date and organisational boundary.

One unofficial account points toward a larger historic physical footprint but remains a lead rather than proof. A consulting firm’s impact page says it advised on TELCOBRAS’s creation and on building and operating a capillary fibre network of more than 130 kilometres in Cali, Buenaventura, Palmira, Buga, Tuluá and Cartago. The claim is specific enough to investigate. It lacks route drawings, completion dates, asset ownership, current lit status and a TELCOBRAS confirmation on the cited page. It cannot support a current 130-kilometre operating-capacity statement without corroboration.

The public legal record also needs measured handling. A Ministry TIC April 2024 notice names TELCOBRAS S.A.S., NIT 900281488, in a collection proceeding and references a payment order dated July 2022. The notice establishes that a proceeding was notified; it does not reveal the present balance, a final adjudication or the company’s current ability to operate. A buyer may reasonably request the disposition and assess continuity implications. It would be wrong to treat the notice alone as evidence of insolvency or a network problem.

Website evidence has a similar boundary. The company’s services and projects are current public representations of what it wants customers to understand. They support the relevance of fibre, hybrid cloud and telemetry to the company’s business. They do not contain objective acceptance tests or dates for most projects. The presence of a contact channel supports ongoing commercial availability, while differences among public addresses invite a basic site and legal-record check. Neither a polished claim nor a stale address settles operations.

Routing observations are stronger for current network state but narrower in scope. Multiple views agree that two IPv4 /24s are active and one upstream is visible. The RPKI validations show disciplined origin authorisation. Yet public BGP cannot reveal optical path diversity, port speed, packet loss, maintenance coverage or a private backup. The PeeringDB absence limits public facility detail but cannot rule out private interconnection. Current route evidence should therefore be called medium-strength for network activity and weak for physical resilience.

Evidence that would change the assessment is straightforward. A current fibre map could show route corridors without disclosing sensitive detail. Carrier letters could identify two diverse handoffs. Interface records could show port rates and utilisation. Facility documents could identify rack, power and cooling boundaries. Project acceptance certificates could establish quantities, dates and maintenance ownership. Backup reports and failover results could show what remains usable.

Until then, the installed-versus-usable distinction must stay explicit: the company demonstrably controls number resources and routes; the capacity behind them is largely undisclosed.

Buyers should ask for survival evidence, not another service label

An enterprise or public authority does not need TELCOBRAS to publish every sensitive network detail. It does need enough evidence to price concentration risk and enforce recovery. The request should begin with the exact service, not the company-wide marketing footprint. Which customer sites, telemetry nodes, applications and user groups must remain available? What minimum capacity and functionality are required during a fault? How long can each function be unavailable before the consequence becomes unacceptable?

For connectivity, the buyer should ask for both circuit endpoints, access media, carriers, facilities, TELCOBRAS edge devices and shared physical segments. A statement that there are two links is insufficient. The response should say whether routes enter the customer site separately, whether they reach different TELCOBRAS and upstream equipment, and whether planned maintenance can remove both. For an AS262191-only design, it should explain which failures the dual arrangement covers and which Liberty-wide failures it does not.

For capacity, normal and degraded states should be separated. The contract should state committed throughput, burst terms, latency and packet-loss expectations where relevant, plus the minimum surviving rate after loss of the primary path. It should disclose whether backup capacity is continuously active, reserved, oversubscribed or activated on request. A successful test should carry representative customer traffic, not merely show that a router can exchange routes.

For hybrid cloud, the customer should know the facility and jurisdiction, the equipment owner, power allocation, cooling dependency, storage design, backup destination, access carriers and support boundaries. Recovery-point and recovery-time targets should be tied to restore tests. If branch access and hosted workloads share AS262929 and AS262191, the end-to-end test should remove that path and prove how users reach the recovered service. If there is no alternate, the risk should be stated and priced rather than hidden behind availability language.

For telemetry, each field asset needs an owner, power plan, communications bearer, maintenance interval and spare strategy. Gateways need coverage and backhaul evidence. Applications need data-quality alarms that distinguish “no hazard” from “no reading.” Public authorities need a manual mode and an alternate notification channel. Acceptance should be repeated after deployment because batteries age, vegetation changes radio conditions, fibre routes are rearranged and contact lists decay.

For the company boundary, the buyer should confirm that TELCOBRAS SAS ESP is the contracting party and identify every material provider underneath. The current corporate registration, regulatory standing and disposition of dated proceedings should be checked without assuming the worst. Insurance, subcontractor access and step-in rights may matter for long-lived public projects. So does the number of people able to restore each layer during simultaneous incidents.

The final test is deliberately simple: remove one dependency at a time and observe the service that users actually need. Cut the primary access logically under controlled conditions. Fail an edge device. Isolate the primary upstream. Restore a workload elsewhere. Disconnect a telemetry gateway from its backhaul. Verify alarms, surviving capacity, data continuity, support escalation and time to recovery. Record which controls worked and which shared dependencies emerged.

TELCOBRAS has enough public evidence to establish a real, active network identity and a plausible enterprise-integration role. Its two RPKI-valid /24s are visible. Its service and project pages connect fibre, hybrid cloud and public-service telemetry in a way that makes the operating question consequential. But the same public record shows only one upstream and withholds the physical and capacity detail needed to convert activity into resilience. The next proof should not be another promise of connectivity from anywhere.

It should show, for a named customer service, what stays connected when the first fibre, rack, power feed or upstream path is gone.