CyberWorld-BKK2 - CyberWorld Data Center Co.,Ltd. has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• CyberWorld-BKK2 is a live network identity, not merely a name. APNIC RDAP records AS136566 as CyberWorld-BKK2 under CyberWorld Data Center Co.,Ltd. in Thailand, while RIPEstat's AS overview marks the ASN as announced.
• The public route surface is small but current. RIPEstat announced-prefix data showed one IPv4 /24, 103.20.120.0/24, and two IPv6 /48s, 2405:2500:5::/48 and 2405:2500:11::/48, in the checked July 2026 window.
• The route hygiene signal is better than the physical-capacity signal. Public checks showed the three prefixes announced, present in Whois route objects, and valid under RPKI for origin AS136566, but they do not disclose rack count, power topology, cooling reserve, facility control or customer failover performance.
• The carrier picture needs caution. RIPEstat's neighbour view showed two observed left neighbours, AS55423 and AS45642, both tied to JasTel Network records; a BGP-state sample was heavily weighted toward AS55423, so the second visible path should not be treated as proven independent carrier diversity.
• Cyber World Tower is relevant but not automatically CyberWorld-BKK2 capacity. APNIC contact records use a CyberWorld Tower address, while public facility records for the tower identify CS Loxinfo or CSL as the operator of the documented data-centre plant. The evidence grade is Medium: the network edge is real, but the marketed data-centre claim still requires direct proof of power, cooling, carrier, facility and recovery boundaries.

BKK2 is live, but live routing is only the first proof

The most useful fact about CyberWorld-BKK2 is that the public internet can see it. APNIC's RDAP record for AS136566 names the autonomous system CyberWorld-BKK2, gives Thailand as the country, records a registration date of 15 May 2017, and lists CyberWorld Data Center Co.,Ltd. as the registrant. APNIC Whois adds the human-readable aut-num record, the company description, the 12/32 Phaholyothin 48 Road organisation address, the CyberWorld Tower network-contact address, and the March 2026 validation note for the abuse mailbox. Those are not marketing claims. They are number-resource and contact records that tie AS136566 to the Thai company.

The corporate record points in the same direction. Data for Thai's company page lists CYBERWORLD DATA CENTER CO.,LTD. under registration number 0105552000659, says the company was registered on 6 January 2009, reports registered capital of 1,000,000 baht, describes the business as internet communication services in all forms, and shows the legal status as still operating. That page is a secondary publication of Thai corporate data, not a certificate for a data hall. It is nevertheless useful because it aligns the company name and Bang Khen address with APNIC's organisation entity.

The route record is stronger still. RIPEstat's AS overview identifies the holder as CyberWorld-BKK2 - CyberWorld Data Center Co.,Ltd. and marks the ASN as announced for the checked date. RIPEstat routing status showed one IPv4 prefix, two IPv6 /48s, broad collector visibility and two observed neighbours. That makes BKK2 different from a dormant registration or a brand phrase copied from a building sign. A routed ASN with current prefix visibility can carry real services, receive real traffic, and fail in ways that affect real users.

The article's central caution is that this positive routing evidence is not the same as proof of data-centre capacity. A live autonomous system can be operated from a cabinet in another company's facility, a small room, a leased rack, a network node, a test environment, or a larger data hall. It can originate a few prefixes without disclosing how many servers exist, what kind of power protects them, whether the cooling plant is shared, which organisation owns the generators, or whether customers have tested failover. The number-resource layer tells us that CyberWorld-BKK2 has a public edge.

It does not, by itself, tell us how the edge survives a feeder outage, a chiller fault, a fibre cut or a failed maintenance window.

That distinction is not pedantry. The company name contains "Data Center", the BKK2 label implies a Bangkok service node, and the contact records point toward CyberWorld Tower. Those signals invite a reader to imagine a full data-centre product. The responsible starting point is narrower: AS136566 is operating; the public record has not yet shown the full facility and recovery boundary behind it.

The route surface is small, clean and current

The current route surface is compact. RIPEstat announced-prefixes data for AS136566 listed 103.20.120.0/24, 2405:2500:5::/48 and 2405:2500:11::/48 in the checked window ending 12 July 2026. RIPEstat routing status counted 256 IPv4 addresses and two IPv6 /48s, with visibility to all 326 sampled IPv4 peers and 320 of 322 sampled IPv6 peers at the query time. It also reported the first-seen route as 103.20.120.0/24 originated by AS136566 on 16 November 2017.

The APNIC prefix records match that picture. APNIC RDAP for 103.20.120.0/24 identifies the IPv4 block as CBW-TH, allocated non-portable, country TH, with CyberWorld technical and abuse contacts. The corresponding APNIC Whois record for 103.20.120.0 includes the route object 103.20.120.0/24 with origin AS136566 and the CyberWorld Data Center Co.,Ltd. description. The IPv6 records also align: 2405:2500:5::/48 and 2405:2500:11::/48 are described as CyberWorld, assigned non-portable, country TH, with route6 objects originated by AS136566.

The routing-authorisation checks were also positive. RIPEstat's prefix overview for 103.20.120.0/24, 2405:2500:5::/48 and 2405:2500:11::/48 showed those resources announced by AS136566. RPKI validation for the IPv4 prefix, the 2405:2500:5::/48 route and the 2405:2500:11::/48 route returned valid status for origin AS136566 in the checked Routinator view. RIPEstat prefix-routing consistency for 103.20.120.0/24 also showed the route present both in BGP and Whois, with APNIC and RADB route objects.

That is a good internet-number result. Many small infrastructure companies show live routes but stale route objects, incomplete RPKI, or unmatched origin records. BKK2's visible route set does not have that weakness in the public checks used here. The IPv4 block is small, but it is not random. The IPv6 /48s are current, separately recorded and valid under the checked route-origin authorisations. For peering and transit diligence, this raises confidence that AS136566 is intentionally operated rather than accidentally visible.

The limit is capacity. A /24 can support customer-facing services, management systems, DNS, NAT pools, mail relays, monitoring, or hosted applications. It cannot reveal how many racks are powered or how much room exists for emergency migration. Two /48s can support modern IPv6 service design, but they do not disclose whether customers actually receive dual-stack service, whether route failover is automated, or whether IPv6 is monitored at the same level as IPv4. Route hygiene is necessary. It is not sufficient.

The carrier evidence points to JasTel, not proven path independence

The neighbour evidence is helpful and easy to overstate. RIPEstat's ASN-neighbours view showed two observed left neighbours for AS136566 on 11 July 2026: AS55423 and AS45642. RIPEstat's AS overview for AS55423 identifies that network as JASTEL-NETWORK-TH-IDC-AP - JasTel Network. APNIC RDAP for AS55423 gives the registrant as JasTel Network Company Limited and places its registered address at Jasmine International Tower in Nonthaburi. RIPEstat's AS overview for AS45642 identifies that ASN as JASTEL-NETWORK-TH-NIX-AP - Jasmine International Tower, and APNIC RDAP for AS45642 also points to JasTel Network Company Limited.

At first glance, two neighbours look like diversity. The BGP-state sample makes the conclusion less comfortable. RIPEstat BGP-state data for AS136566 included 1,075 sampled routes across the three prefixes in the checked response. In that sample, AS55423 was the direct predecessor for 1,072 paths, while AS45642 appeared as the direct predecessor for three paths. Both direct predecessors are JasTel-related, and many observed paths before AS55423 pass through other JasTel identifiers such as AS45629. RIPEstat's AS overview for AS45629 identifies it as JASTEL-NETWORK-TH-AP - JasTel Network International Gateway.

That does not make the service fragile by default. A single well-run upstream or one well-run provider group can be enough for a small data-centre or hosted-service edge if customers understand the risk and if the contract is priced and engineered accordingly. It does mean the route record should not be sold as proof of independent carrier diversity. Logical path variety in a route collector is not the same as two physically independent entrances, two separate commercial providers, two meet-me rooms, two diverse ducts, or two maintenance organisations.

A buyer should ask BKK2 to identify the actual first-hop services behind those ASN observations. Is AS55423 the main transit handoff? Is AS45642 a route-server, exchange, backup or historical path? Are those paths delivered through separate cables, ports, routers and building entries? Does either route share a JasTel aggregation device, billing relationship, maintenance window or facility riser? Can the network carry full customer traffic if the AS55423 path is removed? Has that condition been tested recently?

The public evidence supports one positive statement: BKK2 has visible reachability through JasTel-related networks and can be seen globally. It does not support a stronger claim that customers are protected against a JasTel-side fault, a common building handoff, a shared fibre route or a single commercial dependency. Carrier diversity must be drawn from physical path evidence, not inferred from neighbour count.

Cyber World Tower is a clue, but the operator boundary matters

The location evidence points toward Cyber World Tower, but it does not complete the operating map. APNIC's AS136566 and prefix records list the CyberWorld organisation at 12/32 Phaholyothin 48 Road, while the network administrator and abuse role use 90 CyberWorld Tower, Ratchadapisek Road. That tower address is not a random city label. It is a known Bangkok data-centre and interconnection location.

Public facility records, however, identify a different operator for the documented plant. PeeringDB's facility record for CS LoxInfo Data Center - CW Tower identifies the facility as Cyber World Tower A, 90 Ratchadapisek Road, Bangkok, with CS Loxinfo Public Company Limited as the organisation. It lists two local exchanges and 20 networks, including CSL IDC AS9891, CS Loxinfo networks, Advanced Wireless Network, DTAC, Jastel Network Co.,LTD (Thailand), Symphony, UIH, BKNIX and others. It does not list AS136566 as a facility network in that public record.

BKNIX's Bangkok location page also identifies CSL CW at 90 CW Tower A, floors 17 to 20, with CS LOXINFO contact details and support contacts. BKNIX's own description of why it exists says the exchange is a neutral internet exchange point, offers network connections with a choice of carriers, is located in a data-centre facility with N+1 support infrastructure, and is operated 24x7 by qualified engineers. Those claims support the strength of BKNIX and the CSL CW location. They do not put CyberWorld-BKK2 on the facility floor or under BKNIX's service umbrella.

The CS Loxinfo material is more detailed. The CSLOXINFO IDC@Exchange brochure describes the Cyberworld Datacenter on the fourth floor of Cyberworld Tower A and lists representative systems: two 2,000 kVA transformers in active-standby arrangement, two sets of 400 kVA UPS with N+1 unit redundancy, 2N AC distribution raceways, a 2,500 kVA diesel generator, 48 hours of generator fuel, N+1 precision cooling, six active and one standby cooling units per room, FM200 suppression, two-hour fire-rated walls, leak sensors and a 24-hour network operations contact. Data Center Map's CSL CyberWorld page attributes 1,500 square metres, 385 racks, N+1 redundant systems, 24x7 CCTV, carrier-neutral service and remote hands to CSL at the same address.

These are substantial facility signals. They are also not CyberWorld-BKK2 disclosures. The brochure and directory page attribute the plant to CS Loxinfo or CSL, not to CyberWorld Data Center Co.,Ltd. The existence of a strong data-centre facility in the same named tower can explain why CyberWorld's contact records point there. It can also mislead readers into assigning CS Loxinfo's power, cooling and floor-space claims to a separate legal company and ASN.

The safe conclusion is that CyberWorld-BKK2 may have historical, customer, tenant, network or operational links to the tower, but public sources do not define which racks, systems or responsibilities belong to it.

That operator boundary is the difference between a useful clue and a service guarantee. If CyberWorld-BKK2 leases cabinet space in CSL CW, then CS Loxinfo or CSL may own the most important power and cooling systems while CyberWorld owns routers, servers or customer-facing services. If CyberWorld runs equipment elsewhere and uses the tower address only for contacts, the facility evidence is even weaker. If BKK2 is a brand for capacity inside the tower, then the company should be able to say which systems are its own and which are supplied by the facility operator. Without that disclosure, the public evidence should not be merged.

PeeringDB shows a sibling CyberWorld network, not BKK2 facility proof

PeeringDB adds a second boundary problem. PeeringDB's organisation page for CyberWorld Data Center Co.,Ltd. lists the organisation and shows one network entry: CyberWorld, ASN 136565. It does not present AS136566 as a network on that organisation page. The PeeringDB page for AS136565 describes CyberWorld as an NSP, lists two IPv4 prefixes and three IPv6 prefixes, says the geographic scope is global, records an open peering policy, and lists interconnection facilities at Equinix SG1 and Equinix SG3 in Singapore. APNIC RDAP for AS136565 records the name CyberWorld, country SG, and the same CyberWorld Data Center Co.,Ltd. registrant.

That information is useful because it shows that the company has or had a separate public interconnection profile outside BKK2. It is not BKK2 evidence. AS136565 has Singapore country and Singapore facility entries. AS136566 is named BKK2 and is registered in Thailand. AS136567, the AMS1 sibling discussed in other public records, has a different route state. These are separate network identities. They may share ownership, staff or commercial history, but they should not be folded together when evaluating facility capacity.

For customers, this matters because a company-level interconnection page can create false confidence. If a buyer sees CyberWorld listed at Equinix SG1 and SG3, it may assume that BKK2 has similar public facility disclosure or cross-border failover. PeeringDB does not support that assumption. The visible PeeringDB facility entries belong to AS136565, not AS136566. BKK2's own public route evidence comes from RIPEstat and APNIC, not from a BKK2-specific PeeringDB facility declaration.

The upside is that the company appears capable of keeping at least one public interconnection profile. If CyberWorld-BKK2 wants customers to treat BKK2 as a serious data-centre dependency, it could publish equivalent detail: facility, peering policy, traffic level, public contacts, exchange ports, upstreams, prefixes, route-security practice and maintenance contact. The absence of that BKK2-specific profile is not proof that there is no equipment. It is a reason to ask for more evidence before relying on the name.

The power question is the data-centre question

In data-centre procurement, power is not a background utility. It is the product boundary. Customers do not only need a route to an ASN; they need to know whether the servers, routers, storage, cross-connects, management systems and cooling plant remain alive through credible failures. The public BKK2 record does not disclose those facts.

Thailand's own investment-promotion conditions are a useful benchmark, even though they do not certify BKK2. In the Board of Investment's digital-infrastructure conditions, a promoted data-centre project must provide customer services such as server colocation, managed service, backup, disaster recovery or data hosting; have at least 3,000 square metres; link the data centre to domestic and international telecommunication centres through at least four systems; remain able to serve clients during maintenance or equipment replacement; use continuous-rated generation capable of carrying the full load with backup generation if one generator fails; have UPS and cooling backup that operates immediately after a main-system failure; have independent distribution paths in the electricity system; maintain high-efficiency backed-up air conditioning; provide fire protection across the entire area; and operate 24-hour security. These conditions show the level of evidence Thailand itself uses when a project asks to be treated as strategic digital infrastructure.

BKK2's public evidence does not reach that level. It does not state contracted utility capacity, transformer arrangement, UPS topology, generator rating, fuel autonomy, load-test history, power-distribution design, PUE, cooling topology, cooling reserve, fire-zone design, security scope, certification scope or facility operating responsibility. It also does not state whether BKK2 owns the room, leases cabinets, colocates routers, resells a third-party service or operates a customer platform inside another operator's building.

The CS Loxinfo tower material is a helpful comparison because it shows what detailed data-centre evidence looks like: transformer ratings, UPS sizes, generator runtime, cooling units, leak detection and physical access controls. It is not safe to assign those facts to BKK2 unless CyberWorld or the facility operator states that AS136566's customer service actually sits inside that plant and explains the contractual boundary. The public question is therefore not "does Cyber World Tower have power systems?" Public sources say a CS Loxinfo facility at the tower does.

The question is "which power systems protect CyberWorld-BKK2 services, who operates them, and what load can they support during failure?"

Installed capacity and usable capacity also need separation. A building can have rack shells, a data hall can have gross area, and a network can have visible prefixes. None of those numbers says how much capacity is still available after one UPS module, generator, chiller, router, cross-connect or carrier handoff is unavailable. The decisive number for customers is not normal-state capacity. It is failure-state capacity.

Cooling and fire controls cannot be assumed from the tower name

Cooling is where electrical resilience becomes service resilience. Servers can remain powered while inlet temperatures rise, thermal throttling begins and storage or network equipment shuts down. A reliable service needs cooling reserve, environmental monitoring, alarm response, spare units, maintenance isolation and backup power for the cooling plant itself. Public BKK2 records do not disclose any of that.

The distinction between tower-level evidence and BKK2-specific evidence is again crucial. The CS Loxinfo brochure describes N+1 precision air conditioning and automatic rotation at the Cyberworld Datacenter. Data Center Map lists N+1 redundant electricity and cooling for the CSL facility. BKNIX describes its exchange locations as supported by N+1 infrastructure. These are meaningful statements about other operators or facilities. They do not prove that CyberWorld-BKK2's services are in the same rooms, sold under the same service levels, or protected by the same cooling design.

Fire and water exposure have the same issue. The CS Loxinfo brochure describes FM200 suppression, two-hour fire-rated walls, water-leak sensors and a fourth-floor location. Those controls may reduce risk for CS Loxinfo's IDC@Exchange areas. They do not establish where AS136566's routers, servers, storage or cross-connects sit. A BKK2 buyer still needs to know the actual room, rack line, cable path, fire zone, water-sensor coverage, floor elevation, maintenance access and emergency procedure that apply to the purchased service.

The regional risk context argues against casual assumptions. The World Bank's July 2024 Thailand Economic Monitor describes Bangkok as highly exposed to flood and climate risks, noting the scale of the 2011 floods and the continuing vulnerability of a concentrated urban economy. That does not prove CyberWorld-BKK2 is exposed to a specific flood path. It does show why site elevation, water ingress controls, generator fuel logistics and access planning matter for a Bangkok-linked infrastructure service.

The hard diligence question is not whether a brochure somewhere says "N+1." It is whether the exact BKK2 service can keep customer workloads within environmental limits after a cooling unit, electrical board, pump, controller, fire alarm, leak event or maintenance action. If BKK2 is a network edge inside someone else's data hall, the customer needs the facility operator's evidence and CyberWorld's own service-boundary evidence. If BKK2 owns its own room, the customer needs CyberWorld's direct plant evidence. Either way, public records do not yet settle the matter.

The domain record separates public identity from service placement

The public web domain does not close the operating gap. The company contact records use cyberworld.co.th addresses. Host.io's page for cyberworld.co.th reports the domain as hosted on csloxinfo.com, lists 203.146.249.212 as the A record, shows CyberWorld name servers, and shows Google mail exchangers. APNIC Whois for 203.146.249.212 places 203.146.249.0/24 in the idc-csloxinfo netname, with CSLOXINFO-IDC description and a route object for 203.146.248.0/22 originated by AS9891. RIPEstat's AS overview for AS9891 identifies that ASN as CSLOX-IDC-AS-AP - CS LOXINFO Public Company Limited.

That DNS evidence is not negative. Many infrastructure companies host their public website, mail or name-service components outside the same customer network. External web hosting can even be a resilience choice: a support site or status page can remain reachable if the customer network has trouble. But it means the website cannot be treated as proof of BKK2 service placement. The domain's A record points to a CS Loxinfo address, while the BKK2 network is AS136566 with 103.20.120.0/24 and two IPv6 /48s. Those are different public surfaces.

For customers, the separation matters in both directions. If cyberworld.co.th remains reachable while AS136566 has a routing incident, the company may still be able to communicate but customer workloads may be down. If AS136566 remains reachable while the public website or mail routing has trouble, hosted services may continue while billing or support channels degrade. A serious service review should list which systems sit on AS136566, which are hosted by CS Loxinfo or other providers, which are used for emergency communications, and which have separate authentication and recovery controls.

The same separation affects data placement. An IP geolocation view is not a storage-location guarantee. RIPEstat geolocation for 103.20.120.0/24 and RIPEstat's MaxMind GeoLite view placed the block in Thailand in the checked view. That supports Thai network locality for the IPv4 block. It does not say where customer backups, ticket attachments, administrative credentials, DNS zones, billing records or disaster-recovery copies reside.

A /24 and two /48s can matter without proving large capacity

The BKK2 route footprint is small in IPv4 terms. One /24 provides 256 IPv4 addresses before router interfaces, infrastructure addresses, management space, quarantine pools, spare inventory, NAT design and customer allocations reduce what can be assigned. That is enough for many niche hosting or network services. It is not enough to infer a large multi-tenant data-centre platform, a large address pool for customer migration, or spare public-address room for a broad incident.

The IPv6 picture is better because two /48s can support far more logical addressing. It suggests the operator is not limited to legacy IPv4-only service. But the existence of IPv6 announcements still does not disclose how customers consume them. The public record does not say whether each customer gets IPv6 by default, whether route filtering treats IPv6 and IPv4 equally, whether abuse response covers both, or whether operational monitoring alerts on IPv6 reachability with the same urgency as IPv4.

Capacity also includes bandwidth, not just addresses. RIPEstat can show visibility and AS paths. It cannot show committed information rate, burst capacity, port speed, oversubscription, paid transit commits, exchange-port size, or the rate at which BKK2 can move traffic after a first-hop failure. A network can look globally visible at normal load and still be under-provisioned during an incident. The public BGP view cannot tell whether the AS55423-dominant path has enough spare capacity or whether the AS45642 path is sized only for limited reachability.

The buyer should therefore ask for failure-state numbers. How much traffic can the network carry if the main JasTel IDC path fails? How many customer systems can be moved without public-address exhaustion? How much IPv4 inventory is reserved for restoration, test rebuilds, quarantine and emergency load balancers? Which customers have dedicated addresses, shared addresses or private addressing behind common front ends? Does the service have a bring-your-own-prefix option, and if so, how is it authorised under RPKI and route filters?

None of these questions argues against using a small provider. Small providers can be valuable when they know their limits, maintain clean routing, provide direct support and price the service honestly. The risk begins when the visible network is treated as evidence of larger physical resilience than it can prove. BKK2's route footprint supports a real but bounded service discussion.

Failure paths should be tested one dependency at a time

The assignment's failure paths are exactly the right ones for BKK2: utility outage, cooling failure, carrier-meet interruption, construction or commissioning delay, and facility fire or flood exposure. The public record gives enough evidence to frame those tests, but not enough to mark them passed.

For utility outage, the customer needs the contracted facility, utility feeds, transformer and switchgear arrangement, UPS runtime, generator rating, fuel on site, refuelling terms, automatic-transfer design and the most recent integrated test under load. If BKK2 is inside CSL CW, the customer needs both the facility operator's plant evidence and CyberWorld's service-specific statement about which racks and circuits the service uses. If BKK2 is outside CSL CW, then the CS Loxinfo brochure is only context and CyberWorld must provide its own plant evidence.

For cooling failure, the customer needs the cooling-zone design, rack-density assumptions, reserve margin, environmental monitoring, alarm escalation, hot-aisle or cold-aisle design, backup-power coverage for cooling, and the response time for a failed unit or controller. A cooling claim should state whether the service remains inside safe temperature and humidity limits during planned maintenance as well as unplanned failure. The public BKK2 record is silent on that point.

For carrier-meet interruption, the customer needs a physical route map. The route collectors show AS55423 and AS45642 as observed direct neighbours, with AS55423 dominating the sample. The provider should explain whether those two ASNs correspond to separate ports, separate devices, separate JasTel services, an exchange path, a backup path, or route-server behaviour. It should also show whether a single JasTel maintenance event, a Cyber World Tower riser issue, a shared cross-connect, a commercial suspension, or a common optical platform can remove both paths at once.

For construction or commissioning delay, the issue is whether marketed capacity has actually been energised and accepted. If BKK2 represents a fully operating node, the provider should show current customer service, load, installed and used capacity, and acceptance of critical systems. If it represents a planned expansion or reserved capacity, customers need milestone dates, utility energisation status, fire approval, commissioning tests, carrier delivery and conditions under which service is not yet saleable.

For fire and flood exposure, the customer needs a site-specific risk statement. The World Bank's Bangkok flood context explains why this cannot be dismissed at city level. The provider should disclose floor location, water paths, barriers, drainage, generator and fuel placement, smoke and fire zones, suppression type, staff access during regional disruption, and how customers will be notified if access or fuel delivery is constrained.

Maintenance evidence is where claims become service

Redundancy language can be cheap. Maintenance evidence is harder. A service that is truly concurrently maintainable should remain available while components are isolated, inspected, replaced or upgraded. That means the operator can take a UPS module, generator, switch, router, cross-connect, cooling unit or management system out of service without placing customers on an unprotected chain.

BKK2 has no public maintenance policy in the reviewed evidence. There is no posted notice period, no public status history, no maintenance calendar, no remote-hands scope, no customer escalation matrix, and no published incident history tied to AS136566. That absence does not prove poor operation. Some small providers keep service records private. It does mean customers should not accept a generic uptime claim without asking for recent maintenance examples.

The evidence should be practical. When was the last generator transfer under IT load? When was a UPS module isolated? When was a route moved away from AS55423? When was a cooling unit removed from service while customer equipment stayed within thermal limits? How much customer traffic was on the network during the test? Were customers notified? Did any applications fail? Were changes made afterward?

For network maintenance, the visible route history helps set a baseline. RIPEstat routing history shows long-running visibility for 103.20.120.0/24 since 2017 and later IPv6 history. It also shows periods where peer visibility changed. Those changes can reflect collector coverage, upstream path changes, route policy, maintenance or incidents. The public data cannot tell which. It can guide questions: what happened when visibility dipped in 2023, 2024 or 2025? Were customers affected? Did traffic move to another path? Was there a provider change?

For contact maintenance, APNIC's validation notes deserve attention. The abuse mailbox was validated in March 2026, which is positive. The nmc address is marked invalid in the APNIC IRT remarks, which is a warning sign for operational hygiene. A validated abuse mailbox does not prove a staffed operations desk. An invalid contact does not prove customers cannot reach support. Together they say the customer should verify current support channels, after-hours authority and escalation paths before treating BKK2 as a critical service.

Who is affected when BKK2 fails

No public customer list is available for BKK2. That should stop invented impact claims, but it should not stop dependency analysis. A /24 plus two IPv6 /48s can support websites, portals, application servers, DNS, mail relays, management systems, customer access, reseller services, network appliances or internal services. A small route surface can still be important to the organisations that rely on it.

If AS136566 withdraws all three prefixes, services addressed from that space can disappear from the public internet. If only one path degrades, customers may see partial reachability: fast from some networks, slow from others, reachable over IPv4 but not IPv6, reachable in Thailand but not from abroad, or reachable only through cached sessions. If BKK2 is hosted inside a third-party facility and the facility suffers power or cooling stress, the network may fail even if the external upstream remains healthy.

If the facility remains healthy but a JasTel-side route or commercial issue appears, the servers may continue running while the world cannot reliably reach them.

The affected people may not be network specialists. They may be small businesses whose websites or applications are hosted there, resellers who support local customers, developers who depend on a server for deployment, or organisations that chose a Bangkok-linked provider for local support. The economic harm can be real even when the route table looks small.

The resilience obligation is therefore proportional to the customer's workload, not to the provider's size. A test server or low-risk website can tolerate a small network with limited public disclosures. A payment system, public-service portal, regulated application or mission-critical customer environment cannot. Those customers need written evidence of facility, power, cooling, carrier, backup, recovery and exit terms.

Exit terms matter because a provider can fail administratively as well as technically. Billing access, domain control, backup retrieval, customer authentication, support staffing and legal contact can all determine whether a customer can recover. BKK2's public article should therefore not end at BGP. The same diligence should ask how a customer retrieves data, changes DNS, exports configurations, obtains logs and moves workloads if the service degrades or if commercial terms change.

What would raise the evidence grade

CyberWorld-BKK2 could raise confidence quickly with a concise public operating statement or customer-facing evidence pack. The first item is the asset boundary. The company should state whether BKK2 services are delivered from Cyber World Tower, another Bangkok facility, leased cabinets, owned rooms, reseller space, or a combination. It should name the facility operator where possible and separate building owner, facility operator, network operator, service provider and customer responsibilities.

The second item is power. A useful disclosure would give contracted utility capacity, commissioned IT load, occupied load, saleable reserve, UPS topology, generator rating, generator fuel autonomy, refuelling arrangement, rack power design and the most recent integrated test result. If the service uses another operator's plant, the statement should say which service level and which circuits apply to BKK2.

The third item is cooling and physical risk. The company should state the cooling topology, redundancy basis, maximum rack density, monitoring, alerting, fire suppression, compartmentation, leak detection, flood placement, remote-hands cover and access arrangements during regional disruption. Certification claims should include scope and date. A generic badge or building-level assurance is not enough.

The fourth item is connectivity. BKK2 should identify current upstreams, exchange ports if any, first-hop physical paths, router redundancy, cross-connect diversity, route-origin authorisations, route objects and a tested failover method. The current public record suggests heavy dependence on JasTel-related paths. That may be acceptable, but it should be explicit and sized.

The fifth item is customer recovery. The company should state maintenance notice periods, emergency contacts, response authority, backup and restore terms, data export terms, support hours, customer failover responsibilities, and the most recent real or test exercise in which service continued after a primary dependency was removed. This does not require publishing security-sensitive diagrams. It requires enough evidence for a buyer to understand what survives.

If those elements are supplied, BKK2 can move from "live but physically under-evidenced" to a stronger data-centre profile. Without them, the live route remains important but bounded.

Verdict

CyberWorld-BKK2 earns a Medium network evidence grade. The positive side is clear: CyberWorld Data Center Co.,Ltd. is an operating Thai company in the public corporate record, AS136566 is registered to the company, the ASN is announced, one IPv4 /24 and two IPv6 /48s are visible, route objects and live BGP agree in the checked consistency views, and RPKI validation returns valid for all three advertised prefixes. This is a real network edge.

The downgrade is equally clear. The public record does not prove the service's physical location, rack count, installed or saleable capacity, power topology, cooling reserve, generator runtime, facility operator boundary, customer support arrangement, remote-hands scope, maintenance record, or tested failover performance. The observed neighbour set points mainly to JasTel-related paths, not to proven independent carrier diversity. Cyber World Tower contains documented data-centre and exchange infrastructure, but the strongest public specifications belong to CS Loxinfo or CSL, not directly to CyberWorld-BKK2.

PeeringDB records a CyberWorld sibling network in Singapore, not a BKK2 facility profile.

The right conclusion is balanced. BKK2 should not be dismissed as a hollow label; its routing evidence is too concrete for that. Nor should it be treated as a fully proven data-centre platform merely because it has live prefixes and a tower-linked contact record. The network has already answered the first question: packets can reach AS136566. The remaining question is the one that matters in a data-centre purchase: which powered, cooled, carrier-connected and recoverable system keeps those packets useful when the first dependency fails?