ULTRANET COLOMBIA S.A.S. and the Two-Prefix Edge of AS274310

Summary

ULTRANET COLOMBIA S.A.S. presents UltraNet as a Colombian fibre internet provider with internet-plus-TV offers. Its public materials support an access-network story, not a claim that it operates data-centre, colocation or hosted-infrastructure capacity.
LACNIC records AS274310 as active and assigned to ULTRANET COLOMBIA S.A.S. Public route views show two originated prefixes: 45.196.223.0/24 and 2803:1430::/32.
The IPv6 block 2803:1430::/32 has a direct LACNIC registration to the company. The IPv4 block is announced by AS274310 and located to Cali in UltraNet's geofeed, but its RDAP record points to AFRINIC and Cloud Innovation-related address space; it should not be described as owned by UltraNet.
RIPEstat and bgp.tools expose AS262191, Liberty Networks de Colombia S.A.S., as the one visible BGP neighbour signal in the inspected views. That is a meaningful public dependency indicator, but it does not prove an exclusive physical path or disclose commercial contract terms.
PeeringDB classifies the network as Cable/DSL/ISP, carries a self-reported 20-50Gbps traffic range, and lists no internet exchange or facility records. Public sources therefore describe the logical edge more clearly than the sites, power systems, fibre diversity and recovery arrangements beneath it.

A fibre ISP comes into routing view

The simplest description of UltraNet is also the one best supported by its own public surface. ULTRANET COLOMBIA S.A.S. markets fibre internet and packages that combine internet with television. Its site presents consumer-facing speed tiers and contact points in Cali and Manizales. The language is that of a local access provider: plans, connections, service channels and regulatory information. PeeringDB independently places AS274310 in the Cable/DSL/ISP category. Nothing in those descriptions requires a speculative second identity as a data-centre or colocation operator.

That distinction matters because infrastructure companies are often made to look larger, more vertically integrated or more physically self-sufficient than the evidence allows. A public autonomous system number can sound like proof of a complete facilities estate. A street address can be mistaken for a network site. A traffic estimate can be read as installed switching capacity. A prefix can be treated as property. None of those substitutions is reliable. They collapse different layers of the internet into one convenient but inaccurate picture.

UltraNet's public record becomes more useful when those layers are kept separate. At the service layer, the company says it sells fibre connectivity and internet-plus-TV products. At the registry layer, LACNIC assigns AS274310 to ULTRANET COLOMBIA S.A.S. and directly registers an IPv6 block to the same entity. At the routing layer, public collectors see the autonomous system originate one IPv4 route and one IPv6 route. At the interconnection layer, the same collectors show one visible neighbouring autonomous system.

At the physical layer, however, the available sources do not describe data halls, racks, power feeds, cooling systems, generators, meet-me rooms or carrier entrances.

The result is not a blank profile. It is a sharply bounded one. UltraNet can be examined as a small, newly visible routed network whose retail claims, registry resources, route announcements and public interconnection metadata can be compared. What cannot be done is to fill the gaps with generic language about "infrastructure capacity." The absence of a public specification is itself important to a resilience assessment, but it is not permission to invent the missing specification.

The timing adds to that need for precision. LACNIC's autonomous-system record dates the registration of AS274310 to 2 February 2026 and shows a change the following day. RIPEstat observed it announced in July. PeeringDB's network entity was created in early June and updated later that month. These are signs of a public routing identity that had only recently become visible in the records inspected for this article. They do not establish when UltraNet began serving customers, when every underlying fibre segment was built, or how long any private interconnection may have existed.

They establish a narrower fact: by mid-2026, the company had an active autonomous system with a compact visible route set.

Two prefixes define the observable edge

The visible route set is unusually easy to state. Across the RIPEstat announced-prefix view for the period from 6 July to 20 July 2026, AS274310 originated 45.196.223.0/24 and 2803:1430::/32. bgp.tools showed the same pair, summarising them as one IPv4 prefix and one IPv6 prefix. PeeringDB also reported one prefix in each address family. Three different public surfaces therefore converged on the same small routing outline.

The public boundary is compact enough to inspect route by route, but the two entries are not interchangeable. They reach the routing table through AS274310, and UltraNet's geofeed places both in Cali, but their registry provenance differs materially.

The IPv6 route has the cleaner chain. LACNIC RDAP records 2803:1430::/32 as active, allocated to ULTRANET COLOMBIA S.A.S., and associated with origin AS274310. The company entity record links both the IPv6 network and the autonomous system. Registry holder, route origin and operator identity align in the public record. That does not prove utilisation levels inside the /32, but it does make the authority chain straightforward: the regional registry names the company, and public BGP observations show the company's AS originating the route.

The IPv4 route requires more careful language. Public BGP data shows 45.196.223.0/24 originated by AS274310, and UltraNet's geofeed assigns it to Cali. The RDAP path for the address space, however, does not show a direct LACNIC allocation to the company. It points through AFRINIC records to Cloud Innovation-related space. The route is therefore part of UltraNet's observed operating footprint, but the evidence does not support calling it UltraNet-owned address space.

This difference illustrates why "its prefixes" can be a misleading shorthand. An autonomous system may originate space that it operates under arrangements not visible in BGP. Address registration, route-origin authority, operational use and legal or contractual control are distinct facts. The public sources here establish origin and geofeed use for the IPv4 /24; they do not disclose the agreement under which that use occurs. Describing the block as announced by AS274310 is accurate. Describing it as directly allocated to ULTRANET COLOMBIA S.A.S. would contradict the registry evidence available here.

The RIPEstat routing-consistency view adds another layer. It reported both visible prefixes in BGP and in routing registry data. The IPv6 record was associated with LACNIC, while the IPv4 route drew its internet routing registry signal from RADB. This is not evidence that the two routes perform differently, nor does it resolve the underlying commercial arrangement. It does show that the route objects and registry trails are not uniform. For a two-prefix network, each difference carries more analytical weight because there is no large pool of other origins to dilute it.

A two-route baseline makes future changes conspicuous. A third prefix, a more-specific announcement, a new origin, a new neighbour or a prolonged withdrawal would materially change the public picture. A collector still could not infer customer impact, distinguish maintenance from failure or see private paths.

This is the central value of the two-prefix frame. It is specific enough to resist inflated claims. UltraNet has an observable routed edge. One side is a directly registered IPv6 allocation; the other is an announced IPv4 /24 with separate address-holder provenance. Both are geofed by the company to Cali. Both appear in route-consistency data. Together they define the public address boundary of AS274310 in the inspected period, but they do not define the full physical network behind it.

IPv6 provides the clearest line of authority

The IPv6 record is the strongest piece of resource evidence in the profile because several independent fields align. LACNIC identifies ULTRANET COLOMBIA S.A.S. as the registrant of 2803:1430::/32. It identifies the status as active and allocated. It records AS274310 as the origin autonomous system. It also carries a reference to UltraNet's geofeed. The entity and autonomous-system records point back to the same organisation. There is little ambiguity about who is publicly associated with the resource and who is announcing it.

What that alignment provides is accountability, not a performance certificate. A /32 is a large IPv6 allocation in address terms, but address count is not a proxy for subscriber count, throughput, geographic reach or facility size. IPv6 architecture deliberately provides abundant address space. The allocation can support structured customer and infrastructure addressing without saying how much of it is active. It would be a category error to convert prefix length into commercial scale.

The record does, however, show institutional movement beyond a purely private network identity. UltraNet has a registered autonomous system, a direct IPv6 resource and a published geofeed tying the route to its operator name and a Colombian location. Those elements make troubleshooting and attribution easier for networks that encounter the route. They also create a baseline against which routing hygiene can be assessed. RIPEstat saw the route both in BGP and in whois-derived routing data during the observed window.

There are still important omissions. The sources do not show route-origin authorisation status, customer IPv6 penetration, recursive DNS design, IPv6 security controls, internal aggregation, or whether the IPv6 and IPv4 paths fail together. They do not show whether the same fibre, router, power system or upstream handoff carries both address families. Logical dual stack can coexist with physical common points of failure. The clean IPv6 authority chain should therefore be read as strong administrative evidence and limited engineering evidence.

That limitation is not a criticism of IPv6 registration. It is a reminder that resilience is built across layers. Resource stewardship is one layer. Routing policy is another. Transport diversity, site engineering, access topology and operating practice sit beneath them. UltraNet's IPv6 record answers the first question well: who holds and originates this block? It leaves the deeper questions open.

The IPv4 route exposes a provenance split

The IPv4 /24 is more revealing precisely because its public records do not align as neatly. AS274310 originates 45.196.223.0/24 in the observed BGP views. UltraNet includes the block in its geofeed and assigns it to Colombia, the department of Valle del Cauca and Cali. RIPEstat sees the route in BGP and associates a routing registry entity with it. These facts make the prefix part of UltraNet's visible network operation.

The address registration tells a different, complementary story. The RDAP response is reached through the registry system for AFRINIC space and identifies Cloud Innovation-related holder information rather than a direct allocation to ULTRANET COLOMBIA S.A.S. The correct conclusion is not that the route is improper. Public BGP observation alone cannot establish that, and the available records show no dispute. The correct conclusion is that operational origination and registered address-holder identity are separated in the public record.

Such separation can arise through leasing, delegation, hosting or other arrangements, but naming any particular one here would be speculation. The commercial terms are not public in these sources. Nor do the records establish how long the arrangement will last, what controls exist over routing changes, or what happens to customer addressing if the relationship changes. Those are precisely the questions that borrowed or delegated IPv4 space can raise, even when day-to-day routing is stable.

For customers, the distinction is unlikely to be visible during ordinary browsing. Packets follow routes, not corporate registry narratives. For operators and risk analysts, however, the distinction matters because it identifies another possible dependency surface. Directly held address space and externally sourced address space can have different administrative failure modes. Route authorisation, abuse handling, reassignment, renewal and emergency coordination may involve different parties. None of those risks is shown to have tracked here; the records simply establish that more than one institutional layer exists.

The geofeed adds useful but limited precision. UltraNet's file names AS274310, the company, its LACNIC organisation identifier and contact details, then maps both visible prefixes to Cali. Geofeeds help other systems associate address ranges with intended locations. They are operator-published assertions, not measurements of router position or proof of a building. A prefix can be geofed to the market it serves while traversing infrastructure elsewhere. The Cali entries therefore support service-location and geolocation intent, not a claim that every relevant router, handoff or data-processing asset sits within city limits.

The /24 size also deserves restraint. It is the conventional minimum IPv4 route length widely accepted in global routing, but the evidence here supports only the route itself. It does not reveal how addresses are divided among subscribers, network equipment or services. It does not show utilisation, address-sharing policy or customer density. A small public IPv4 block can support a larger access base through address translation; it can also be lightly used. The route count cannot decide between those possibilities.

What the IPv4 evidence does allow is a better question. Instead of asking whether UltraNet "owns" the route, an observer can ask which responsibilities belong to the origin operator and which remain with the registered address-space chain. Who maintains route objects? Who coordinates an abuse or hijack incident? What continuity plan exists if the address arrangement changes? Public sources do not answer those questions, but they make the questions visible.

That is a more useful form of infrastructure intelligence than forcing a false binary between ownership and non-ownership. AS274310 is visibly announcing the prefix. UltraNet is visibly geofeeding it. AFRINIC and Cloud Innovation-related records remain part of its address provenance. All three statements can be true at once. Preserving that complexity is essential to an honest account of a small network's dependency boundary.

One visible neighbour, carefully described

The most consequential routing signal in the public views is AS262191. RIPEstat's neighbour data showed one unique observed neighbour for AS274310 on 20 July 2026. Its routing-consistency output showed imports and exports involving AS262191 in BGP, although that relationship was not reflected in the whois policy data shown by the same service. bgp.tools listed AS262191 in its upstream and peer presentation for both IPv4 and IPv6. The named network is Liberty Networks de Colombia S.A.S.

Taken together, those observations justify describing Liberty Networks de Colombia S.A.S. as the one visible BGP neighbour or dependency signal in the inspected public route views. They do not justify every stronger formulation that might be tempting. They do not prove that UltraNet has only one physical circuit. They do not prove that no private peer, backup tunnel or unobserved route exists. They do not establish an exclusive commercial upstream contract. They do not reveal pricing, service levels, capacity commitments or termination rights.

The distinction between a visible autonomous-system adjacency and a physical path is fundamental. Two BGP sessions can run over fibres that share a duct. One BGP relationship can be delivered over physically diverse circuits. A backup may remain invisible until activated. Route collectors see selected control-plane announcements from selected vantage points; they do not inventory every cable or contract. The present evidence is therefore strong about the public routing topology and weak about the full transport topology.

Even with that caution, the signal matters. A small origin whose publicly visible IPv4 and IPv6 routes both reach collectors through the same neighbouring AS presents a concentrated observable edge. If the relationship is the effective path for both families in normal operation, incidents affecting policy exchange or reachability across that edge could have broad consequences for the routes. The word "could" is doing necessary work: no outage evidence in the sources proves such an event, and no topology map shows all alternatives.

The neighbour's identity also places UltraNet within a wider Colombian connectivity environment without proving organisational integration. Liberty Networks de Colombia S.A.S. is a separately named network. Public routing data connects the two autonomous systems at the control-plane level. It does not turn one into a subsidiary, customer or facility of the other for purposes beyond the observed route relationship. The safest description remains the most informative one: AS262191 is the sole neighbour visible in the inspected datasets, across both address families.

For resilience analysis, the practical question is not simply "How many upstreams?" It is "How many independently failing paths carry each critical route, and which dependencies are shared?" Answering that would require operator disclosure or measurements not present in the public record: circuit diversity, handoff sites, physical carriers, route-policy design, failover tests and perhaps traceroute evidence from multiple networks. Counting one visible neighbour is a starting point, not a final topology.

This careful language avoids two opposite errors. One would minimise the public signal because BGP is incomplete. The other would turn the signal into proof of absolute single-homing. The evidence supports a middle position. AS274310 has a concentrated public dependency boundary in the views examined. That boundary deserves monitoring and questions about diversity. It does not establish that UltraNet's entire physical network has only one way out.

Cali and Manizales describe different parts of the footprint

UltraNet's public location evidence does not collapse into one city. The company site presents contact or service information for both Cali and Manizales. Its geofeed maps the two visible prefixes to Cali. LACNIC's entity record uses a Manizales registrant address, while the autonomous-system contacts include signals associated with both cities. This split is best treated as evidence of different administrative and operating contexts, not as a contradiction that must be forced into a single headquarters narrative.

Cali is the stronger signal for the routed customer-facing footprint in the public record. Both the IPv4 /24 and IPv6 /32 are assigned to Cali in the company's geofeed, including the Valle del Cauca regional code and a Cali postal code. The company site also markets services and gives contact information there. Those facts support the proposition that Cali is an important service or operational geography for UltraNet.

Manizales is the stronger registry and organisational contact signal. LACNIC lists the registrant in Manizales and connects that entity to AS274310 and the IPv6 resource. UltraNet's public pages also contain a Manizales contact point. It is therefore not an incidental city appearing only in a third-party listing. The public record supports a two-city company footprint, even though it does not explain the division of functions between them.

What it does not support is a physical network map. A contact office is not necessarily a point of presence. A registrant address is not necessarily a router site. A geofeed city is not necessarily where traffic exits to an upstream. The source material provides no verified coordinates for aggregation nodes, headends, exchange ports or carrier handoffs. Any attempt to label one address as a data centre or network operations centre would outrun the evidence.

There is also a minor street-address inconsistency across inspected company material in Cali, with the street number rendered as either Calle 51A or Calle 52A in different page contexts. That is a reason not to build an argument around the precise address. At city level, the evidence is robust enough to use. At building level, it needs confirmation. This is a good example of why infrastructure research should preserve the resolution of the source rather than pretend every field is equally settled.

The two-city pattern raises legitimate operational questions. Are Cali and Manizales separate access markets, administrative centres or both? Does either city host routing equipment? Are network functions duplicated between them? Do fibre paths between the cities provide resilience, or are the public contacts unrelated to backbone topology? None of these questions can be answered from addresses and a geofeed alone.

For UltraNet, the accurate geographic conclusion is therefore deliberately modest. The company has public service, contact and registry ties to Cali and Manizales. Its published geofeed associates both visible routed prefixes with Cali. Its LACNIC registrant evidence points to Manizales. The sources do not disclose how those city signals map onto physical topology, capacity or recovery design.

What PeeringDB says, and what an empty listing does not say

PeeringDB's record is unusually informative for a young, small AS because it supplies a self-description beyond the route table. ULTRANET COLOMBIA is listed with the long name ULTRANET COLOMBIA S.A.S. and ASN 274310. The network type is Cable/DSL/ISP, the scope is South America, the traffic ratio is described as mostly inbound, and the traffic level is self-reported in the 20-50Gbps band. The peering policy is open.

Each field needs its own evidentiary weight. The network type reinforces the company's retail fibre positioning. A mostly inbound ratio is plausible for a consumer access network, where users tend to receive more content than they send, but the label is self-reported rather than measured in the source. The traffic band is also self-reported. It is not an audited throughput result, a committed capacity figure, a peak measurement or a statement about usable capacity during a failure.

The difference between traffic and capacity is especially important. A network carrying traffic within a stated range may have substantially more interface capacity, or it may operate closer to a constraint at certain times and locations. Aggregate traffic says nothing by itself about congestion on a last-mile segment, the headroom of an upstream link or the redundancy of an aggregation router. It should not be converted into a claim that UltraNet owns 20-50Gbps of upstream capacity, still less into a claim about data-centre scale.

The record's empty sections are also relevant. PeeringDB reports no internet exchange entries and no facility entries for the network. That means the directory does not publicly identify an exchange port or facility association for AS274310. It does not mean that UltraNet has no equipment site, no private interconnection and no physical facility of any kind. PeeringDB coverage depends on what entities submit, and private arrangements may not appear.

This is where absence can be informative without becoming proof. For an analyst trying to verify a colocation or interconnection story, the record supplies no supporting facility name, exchange, port speed or public meeting point. Combined with the company's consumer-access marketing, that absence argues against portraying UltraNet as a documented data-centre operator. But it cannot prove the non-existence of an unlisted rack, shelter, office equipment room or carrier handoff.

The open peering policy deserves similar restraint. It signals willingness, at least in the directory profile, to consider interconnection without requiring a particular location or contract condition. Yet the same profile exposes no public place where that policy is exercised. There is no listed exchange fabric or facility cross-connect. Public route views still show only AS262191 as a neighbour. The policy is therefore a statement of posture, not evidence of a diversified present topology.

Taken as a whole, PeeringDB tells a consistent story. UltraNet identifies as an access ISP with a regional scope and a relatively compact traffic band. It signals openness to peering. It does not publish the interconnection locations or facility memberships that would allow outsiders to trace that ambition into physical redundancy. The record adds context to AS274310 while leaving the most important site-level questions unanswered.

A regulatory surface without a completed regulator check

UltraNet's own website displays Registro Unico de TIC No. 96005573. Its legal information page repeats the number alongside other disclosures. This is meaningful company-published evidence that the provider represents itself as registered within Colombia's ICT framework. The public MinTIC lookup entry point did not yield usable static confirmation. The number should therefore be attributed to the company, not presented as independently verified by the regulator.

That attribution may sound overly cautious, but it preserves an important distinction. A company's publication of a registration number can be accurate and useful while still being a different evidentiary event from retrieving the matching regulator record. The available material supports the first. It does not complete the second. An interactive MinTIC check could close the gap later without changing what UltraNet currently publishes.

The legal page provides other signals of operating maturity. It describes traffic-management measures as reasonable and non-discriminatory and says content is not blocked except where legally required. It exposes links labelled as service indicators for 2024 and 2025. It also links a personal-data-protection document that was available as a PDF. These elements show a public disclosure surface around network management, service reporting and data policy.

They do not supply every underlying fact. The linked service-indicator spreadsheets could not be reliably examined, so no complaint rate, service metric or quarterly value can be responsibly quoted here. The existence of the links is supported; their numerical contents are not. Likewise, the availability of a data-protection PDF proves that a policy document is published, not that any particular network control or security outcome has been audited.

The traffic-management statement is relevant to how the company describes its service principles, but it is not a measurement of congestion or neutrality in practice. Such claims would require technical observation, enforcement records or a more detailed policy review. The public page establishes the provider's stated approach. It does not reveal queue design, oversubscription, peak utilisation, application-specific treatment or incident history.

This regulatory surface belongs in the infrastructure profile because operational accountability is part of network resilience. Customers need a provider identity, contact path and disclosure framework when service fails. Yet compliance-facing pages cannot substitute for engineering disclosure. A registration number does not prove route diversity. A privacy policy does not prove backup power. A service-indicator link does not reveal fibre repair times until its contents can be examined. The record is useful when its layers remain distinct.

The physical resilience story is still missing

Public routing data can be precise while physical infrastructure remains opaque. That is the defining tension in UltraNet's profile. AS274310, its two routes, the direct IPv6 allocation, the externally registered IPv4 space, the geofeed and the visible AS262191 relationship can all be described with specificity. The sources do not provide comparable detail about the sites and systems that keep those routes available.

There is no verified public specification here for data-centre halls, colocation inventory, rack count, server rooms, power feeds, battery autonomy, generator runtime, fuel arrangements, cooling redundancy or fire suppression. There is no named carrier meet-me room, no facility list and no exchange port. There is no map of aggregation nodes, backbone spans, access rings or upstream handoff points. There is no disclosed recovery-time target or evidence of a failover test.

That does not prove those capabilities are absent. An ISP must operate equipment somewhere, and a fibre service necessarily depends on physical plant. The analytical point is narrower: the present public sources do not verify the form, ownership, location, scale or resilience of those assets. Calling them a data-centre estate would be fabrication. Calling their absence from public directories proof that they do not exist would be equally unsound.

For customers, the unanswered physical questions may matter more than the clean registry facts. A route can remain correctly registered while a neighbourhood loses power. Two address families can disappear together if they share one router. Multiple fibre strands can fail together if they occupy one duct. A backup circuit can be useless if it terminates in the same building or depends on the same upstream core. Conversely, a network with one visible BGP neighbour might have carefully engineered internal redundancy that public collectors cannot see.

The route table cannot resolve these possibilities. It provides control-plane reachability as seen from external vantage points. It does not expose passive optical network splits, feeder routes, cabinet batteries, pole access, splice inventories, field crews or repair stocks. It cannot show whether Cali and Manizales are independent operational zones. It cannot tell whether the IPv4 and IPv6 services share every failure domain.

This is why the phrase "single point of failure" should be used only after the point has been identified. AS262191 is a single visible neighbouring AS in the inspected route views. That is a concentration signal. The record does not identify a single fibre, router, building or contract whose failure is proven to isolate UltraNet. A responsible resilience assessment says where concentration is observed and where the topology remains unknown.

From that perspective, the most significant public gap is not a missing promotional page. It is the absence of fault-domain information. Which equipment and links are duplicated? Where do ostensibly diverse paths converge? How long can key nodes operate without grid power? Which address resources and route policies can be moved during an incident? How are customers informed? Public evidence does not answer these questions.

The correct response is neither dismissal nor alarm. UltraNet's visible routing footprint is coherent enough to monitor. The IPv6 authority chain is clear. The IPv4 provenance split is describable. The public neighbour signal is consistent across more than one routing source. Those are substantive facts. They become more valuable, not less, when the limits are recorded alongside them.

The questions a resilience review should ask

A deeper review of UltraNet would start below the autonomous-system layer. The first set of questions concerns transport diversity. Does AS274310 reach AS262191 through more than one circuit? Are those circuits delivered over separate fibre routes and entrances? Do they terminate on separate routers, power domains or sites? Is there a standby path through another autonomous system that is invisible in ordinary collector views? A count of BGP neighbours cannot answer any of these.

The second set concerns routing policy. Are IPv4 and IPv6 announced under the same failure and maintenance procedures? Are route filters, maximum-prefix limits and origin validation used at the external edge? How quickly can the network withdraw or replace a route during an incident? Does the IPv4 address arrangement create additional coordination steps with the registered address-space chain? The public consistency data shows the routes and an observed peer relationship, but not the operational controls around them.

The third set concerns the access network. Fibre service can fail at many layers that never appear in global BGP: an optical line terminal, feeder cable, passive splitter, cabinet power supply, local aggregation switch or backhaul span. How many customers share each critical element? Are feeder routes ringed or radial? What telemetry detects optical degradation before a full outage? What spares and field capacity are available in Cali and Manizales? These are material infrastructure questions even when the global routes remain visible.

Power is another unclosed domain. Which network nodes have batteries, and for how long under realistic load? Which sites have generators? How is fuel resupplied during a prolonged city outage? Are upstream handoffs protected by the same or different utility feeds? No claim about power redundancy can be drawn from a website plan, an ASN registration or a PeeringDB traffic range. Direct operator evidence would be needed.

The geography should be clarified at operational resolution. Which functions are performed in Cali and which in Manizales? Do both cities originate or aggregate customer traffic? Is the geofeed location a market assignment, a routing location or both? Are there independent network-operation capabilities in each city? The current records show both cities but do not explain their topology.

The IPv4 arrangement deserves a continuity answer. UltraNet visibly announces 45.196.223.0/24, while the RDAP holder chain is Cloud Innovation-related AFRINIC space. What is the operational basis for the announcement? How is route authority documented? What migration plan exists if the block becomes unavailable? Would subscribers or public-facing services need renumbering? These questions are not allegations; they are standard continuity questions wherever origin and direct allocation do not align.

The IPv6 deployment deserves a customer-facing answer too. The direct /32 gives UltraNet ample administrative space, but is native IPv6 delivered across its retail footprint? Are customer devices delegated stable prefixes? Is support equivalent in Cali and Manizales? Does monitoring cover both address families independently? A globally visible route establishes reachability at the edge, not the quality or reach of service behind it.

Finally, any claim of data-centre, colocation or hosted-infrastructure capability should be tested against concrete assets. What facility is being described? Who operates it? What power, cooling, physical security and carrier-diversity specifications are public? Is PeeringDB missing an association, or is the claim simply inapplicable? Until evidence answers those questions, UltraNet should be described according to what is documented: a fibre ISP operating AS274310.

These questions are useful because they follow the dependencies already visible rather than importing a generic checklist without context. The two-prefix edge makes address continuity important. The one visible neighbour signal makes path diversity important. The two-city evidence makes fault-domain geography important. The absence of facility records makes physical claims particularly sensitive. A good review would close those specific gaps.

What to watch as AS274310 matures

Because the current public routing footprint is small, changes should be relatively easy to detect. The first indicator is prefix count. New aggregate or more-specific routes could reflect growth, traffic engineering, a resource change or an incident. A change in origin for either current prefix would deserve examination, especially for the externally registered IPv4 block. A disappearance would need duration and multi-vantage confirmation before being labelled an outage.

The second indicator is neighbour diversity. If another autonomous system begins appearing next to AS274310 across public collectors, that would alter the visible dependency boundary. It would not automatically prove physical diversity; two upstream AS paths can still share transport. But it would be a meaningful change from the single-neighbour baseline described here. PeeringDB exchange or facility entries would add context if they appeared.

The third indicator is registry alignment. The IPv6 chain is already direct and clear. Changes to the IPv4 RDAP record, new directly held IPv4 resources, updated routing entities or additional geofeed entries could clarify the address strategy. None should be interpreted in isolation. Registry status, BGP origin, geofeed and routing policy data need to be compared.

The fourth is geographic disclosure. More precise service maps, verified points of presence or separate city-level network information could explain how Cali and Manizales relate. Facility evidence, if published, should be evaluated for actual engineering content rather than labels. A named site without power, path and operator details would still leave resilience questions open.

The fifth is the company's own accountability surface. An independently confirmed MinTIC registration lookup would strengthen the regulatory record. Accessible service-indicator reports could add longitudinal evidence. Clear incident and maintenance communication could show how the provider manages operational events. These disclosures would complement rather than replace route monitoring.

Monitoring must also respect what public data cannot see. RIPEstat and bgp.tools are valuable external views, but neither is an omniscient map. PeeringDB is a entity-maintained directory, not an audit. RDAP records resource responsibility, not installed capacity. UltraNet's website expresses the company's services and policies, not an independent performance test. Conclusions should change only when the type and quality of evidence change.

A visible network with an invisible foundation

ULTRANET COLOMBIA S.A.S. has a public network identity that is narrow but substantive. AS274310 is active. Two prefixes are visible. The IPv6 /32 is directly tied to the company in LACNIC. The IPv4 /24 is originated and geofed by UltraNet while remaining part of an AFRINIC and Cloud Innovation-related registration chain. AS262191, Liberty Networks de Colombia S.A.S., is the one neighbouring AS visible in the inspected BGP views.

Those facts describe an operating boundary. They do not describe a data centre. They do not disclose how many physical upstream circuits exist, whether routes are transported over diverse paths, where the critical routers sit, how sites are powered, or how Cali and Manizales divide operational responsibility. PeeringDB's lack of facility and exchange entries reinforces the absence of public interconnection detail, but it cannot prove the absence of private infrastructure.

The most defensible account of UltraNet is therefore neither expansive nor dismissive. It is a Colombian fibre ISP whose autonomous-system footprint became publicly legible in 2026 and whose visible edge is concentrated enough to merit close observation. The clean IPv6 resource chain is a strength of the record. The IPv4 provenance split and single visible neighbour are dependency questions. The missing physical specifications are unresolved, not negative facts.

Infrastructure analysis is often strongest at precisely this boundary between what can be seen and what cannot. AS274310 gives outsiders a route-level baseline. It also shows why route-level evidence must not be used as a substitute for site-level resilience. UltraNet's next chapter will be easier to assess if its public record grows not merely in prefixes or traffic claims, but in verifiable answers about diversity, continuity and the physical systems beneath the routes.