Virtual Data Center Inc has to prove whether marketed data-centre

Summary

RIPE RDAP for AS199152 identifies the autonomous system as VDC-USA and links it to Virtual Data Center Inc, with a Wyoming address for the organization record. RIPEstat's AS overview showed AS199152 announced on the 2026-07-12 observation window.
RIPEstat routing status showed six IPv4 prefixes and twenty-eight IPv6 prefixes, with full observed RIS visibility for both IPv4 and IPv6 and two observed neighbours. That is enough to treat the company as a live routing subject, not enough to treat marketed capacity as proven.
RIPEstat announced prefixes listed current IPv4 routes including 91.239.23.0/24, 146.19.84.0/24, 194.8.6.0/24, 195.242.147.0/24, 212.22.75.0/24 and 213.21.222.0/24, plus a larger IPv6 surface. Most tested origins were RPKI valid; 194.8.6.0/24 returned unknown, not invalid, in the checked result.
The facility evidence remains weak. The AS record and route collectors show a network, while Versija's public material describes VERnet DC in Riga and AS8285 appears as a visible neighbour; neither fact proves that Virtual Data Center Inc controls a data centre, owns racks, has dual utility feeds, stocks spare hardware, or can fail customers over during a power, cooling or carrier incident.
The public evidence grade is Medium for the network and weak for capacity assurance. Buyers should verify the exact site, rack boundary, upstreams, power design, remote-hands terms, maintenance policy and recovery path before treating the company name as usable data-centre resilience.

A data-centre name is not a data-centre audit

Virtual Data Center Inc is the kind of infrastructure name that can create more confidence than the public record deserves. The words suggest a hosted estate: servers, virtual machines, address space, power, cooling and access to carriers. The routing record confirms part of that picture. RIPE RDAP names AS199152 as VDC-USA and links it to Virtual Data Center Inc. RIPEstat marks the AS as announced. BGP.tools likewise presents AS199152 as active under RIPE, with six IPv4 and twenty-eight IPv6 originated prefixes in its view.

That is a useful starting point, but not a full answer. A network can be visible without proving where the servers sit, who operates the rooms, how many cabinets are in use, whether there is more than one powered path, or whether customers can survive a facility incident. A data-centre company can control its own building, lease a suite, rent cabinets, resell another operator's capacity, run only address-space and routing services, or combine several of those models. Public routing data can narrow the questions. It cannot replace site, contract and failover proof.

The company's own current web surface was not a strong source in this review. The assigned domain, virtualdc.io, did not provide a usable public marketing or technical service page during the checks for this article. That matters because a company selling data-centre or hosted-infrastructure capacity normally uses its site to describe service locations, product boundaries, support terms, power design, carrier mix, or at least a contact path. When the public site is unavailable or uninformative, the route table becomes the main evidence source. The route table can show that something is being announced; it cannot show that customer workloads are protected.

The correct reading is therefore disciplined. Virtual Data Center Inc should be treated as a live network subject because AS199152 is visible and registered to the company. It should not be treated as a proven data-centre operator merely because its name and route count imply physical infrastructure. The article tests the gap between marketed capacity and usable resilience: power availability, cooling, fibre meet-me access, facility operations, local permits, route diversity and customer recovery.

The clean identity anchor is AS199152

The strongest identity evidence is the RIPE record. RIPE RDAP for AS199152 gives the AS name as VDC-USA, status active, and an organization entity named Virtual Data Center Inc. The related RIPE organisation record lists ORG-VDCI2-RIPE, country US, a Wyoming registration number, and an address at 30 North Gould Street STE R, Sheridan, Wyoming. The RIPE aut-num entity also links AS199152 to ORG-VDCI2-RIPE and shows the AS name VDC-USA.

That record anchors the directory entity. It does not anchor the physical site. The number-resource record is a registry entry for a network identity and related contacts. It is not a data-centre lease, power single-line diagram, cabinet inventory, customer SLA or operations runbook. It also sits in the RIPE database even though the organisation record describes a U.S. company. That is not unusual by itself, but it is an early warning that the legal address, number-resource registry, service market and physical estate may not all be in the same jurisdiction.

The public route geography reinforces that warning. The RDAP record for 91.239.23.0/24 shows a Latvia country code and a RU-VIRTUALDC name. The 146.19.84.0/24 record and 195.242.147.0/24 record also show Latvia country codes and RU-VIRTUALDC naming. Other announced IPv4 records, including 212.22.75.0/24 and 213.21.222.0/24, are also Latvia-coded in RDAP. Those records do not prove a customer server is in Latvia, but they make a purely U.S. physical reading hard to support.

This distinction matters for customers. A U.S.-registered company can be a valid contracting party while the equipment or upstream dependency sits in Europe. A RIPE record can identify an organization while the real repair path runs through another operator's building, engineers and power design. A buyer that cares about latency, data locality, sanctions exposure, outage escalation or court jurisdiction needs to ask all of those questions directly. The public record does not answer them.

The visible route surface is real and moderately broad

The route surface is the part of the record that looks strongest. RIPEstat routing status for AS199152 showed the resource announced in the 2026-07-12 query window, with six IPv4 prefixes covering 1,536 IPv4 addresses and twenty-eight IPv6 prefixes covering 606,209 /48s in the returned summary. It also showed both IPv4 and IPv6 visibility across the RIS peers in that result. That is not a trivial dormant shell.

The announced-prefixes view listed the current IPv4 surface as six /24s: 91.239.23.0/24, 146.19.84.0/24, 194.8.6.0/24, 195.242.147.0/24, 212.22.75.0/24 and 213.21.222.0/24. It also listed many IPv6 routes, including 2a12:6700::/32, 2a12:6705::/32, 2a12:6706::/32, 2a11:8480::/32, 2a11:8484::/32, 2a11:7e41::/32 and multiple 2a0a:2e86 sub-allocations. BGP.tools presented the same high-level count, while CAIDA AS Rank identified AS199152 as VDC-USA for Virtual Data Center Inc and showed a small customer cone.

RPKI checks were also mostly positive for the tested surface. 91.239.23.0/24, 146.19.84.0/24, 195.242.147.0/24, 212.22.75.0/24, 213.21.222.0/24, 2a11:8484::/32 and 2a12:6700::/32 returned valid results in the checks used here. 194.8.6.0/24 returned unknown. Unknown is weaker than valid, but it is not the same as invalid.

Those facts support a real network assessment. AS199152 is not just a name in a directory. It is announcing a meaningful, if not large, route set. Customers can monitor it, compare public prefixes, watch origin validation and ask whether their purchased service actually uses one of those prefixes. That is the positive side of the evidence.

The negative side is that route count is not capacity count. Six IPv4 /24s and a large IPv6 announcement can support many different business models: VPS hosting, anycast services, anti-abuse services, address leasing, transit resale, private customer connectivity, or other hosted infrastructure. The route table does not disclose rack power, CPU headroom, storage arrays, spare drives, cooling units, fire protection, remote hands or customer isolation. The route table can tell a buyer where to look. It cannot tell the buyer how long a failed server stays down.

Registered routing intent is broader than observed paths

The route-policy record adds a second layer. The RIPE aut-num entity includes route-policy entries naming AS48108, AS212706, AS57724 and AS8285. RIPEstat's routing-consistency view showed those four peers in the registry side of the comparison, while only AS212706 and AS8285 were observed in BGP at the checked time. The same result showed the current in-BGP IPv4 routes and several additional registry routes that were not observed.

That difference is not automatically bad. Route-policy entities often retain planned, backup, historic or low-visibility relationships. A network may have a protected path that does not appear in one collector window, or a relationship may exist for only a subset of routes. But the distinction matters because resilience claims depend on observed and usable diversity, not just named peers. A buyer should ask which upstreams are active for the exact service, which are failover-only, which are DDoS-related, which are legacy, and which carry customer traffic during maintenance.

The two observed neighbours point to a mixed operating context. RIPEstat's AS neighbour data showed AS8285 and AS212706. RIPEstat's overview for AS8285 identifies it as Versija SIA, while BGP.tools for AS8285 shows Versija SIA as a Latvian network with multiple upstreams. RIPEstat's overview for AS212706 identifies LIVI HOSTING LTD. Those are public routing identities, not proof of contract depth.

The registry-only peers are also relevant. RIPEstat identifies AS48108 as VIRTUALDC Dmitrii Vladimirovich Malkov and AS57724 as DDOS-GUARD LTD. If those entries are current, they may reflect an internal related network, a protective route path, a provider dependency, or a policy configuration that is not currently visible from the checked vantage point. Public evidence cannot settle which interpretation is right. The important conclusion is narrower: the public route record is not the same as a proven multi-carrier architecture.

The absence of a public PeeringDB profile for AS199152 caps the confidence further. PeeringDB absence does not mean a network is weak. Many networks do not maintain public profiles. But when a company asks the market to trust data-centre capacity, a PeeringDB profile can help corroborate facilities, exchanges, interconnection policy and contacts. Here, that corroboration is missing for the company AS. The buyer must therefore get facility and carrier evidence from the company or from the upstream facility operator, not from a public exchange directory.

Latvia is the clearest physical clue, not the whole answer

The strongest physical clue is the repeated Latvian context around the route surface. Several announced prefixes carry Latvia country codes in RIPE RDAP. AS8285, one of the observed neighbours, is Versija SIA. Versija's public site describes business internet, hosting, networks and channels, and a data-centre business. Its data-centre page says Versija has offered customer server colocation since 1996 and describes VERnet DC in Riga, including uninterruptible power supply, climate control, high-speed connections to local exchanges and several independent international data-transfer channels. The VERnet DC site advertises VPS, dedicated servers, server hosting and rack rental in Riga. PeeringDB for AS8285 lists Versija SIA as an NSP and PeeringDB netixlan data shows a SMILE-IXP connection.

Those facts are useful, but they must be handled carefully. They do not prove Virtual Data Center Inc has racks in VERnet DC. They do not prove a formal colocation contract, a cabinet count, a suite, or power draw. They show that a visible neighbour has a data-centre and network services footprint in Latvia, and that AS199152's public route geography is consistent with a Latvian dependency. That is an operational clue, not a facility certificate.

If Virtual Data Center Inc uses Versija facilities or transit, the resilience questions become specific. Does the company lease its own cabinets, buy virtual servers, rent dedicated servers, colocate routers, or only use upstream connectivity? Which power feed reaches the equipment? Is there generator coverage and fuel runtime? Does customer traffic cross one meet-me path or multiple diverse risers? Is there a second upstream available inside the same room? Does the company have remote-hands rights after hours? Are spare optics, disks and power supplies on site?

If the company does not use Versija facilities directly, the questions are still similar. The buyer should identify the actual facility operator and the route between the facility and AS199152. The public evidence makes Latvia a likely part of the dependency map; it does not name the customer failure domain. The job of diligence is to turn "likely dependency" into "tested dependency" before important workloads move.

This is where data-centre wording can mislead. A hosted-infrastructure buyer may see a company name, an ASN and a set of prefixes and assume the operator controls the physical stack. The public evidence here supports a more cautious statement: Virtual Data Center Inc controls or is responsible for a visible routing surface, and that surface appears to depend on European, especially Latvian, network infrastructure. The control boundary below that surface remains undisclosed.

Power and cooling are the missing tests

The assignment for this company starts with a physical dependency: power availability, cooling, fibre meet-me access, facility operations and local permitting. Those are exactly the areas the public record does not prove. RIPE records and route collectors are strong at naming numbers and paths. They are weak at exposing utility design.

A data-centre service can fail even when BGP remains configured correctly. A single UPS string can trip. A generator can fail to start or can run out of fuel. A cooling loop can lose capacity during a heat event. A fire alarm can shut down access. A facility can enter a maintenance window that reduces redundancy. A city permit, landlord dispute or electrical inspection can delay new capacity. A meet-me room incident can isolate a rack even if the upstream provider remains healthy. None of those risks appears in an AS record.

For Virtual Data Center Inc, the public evidence does not show dual utility feeds, generator runtime, UPS topology, cooling redundancy, rack density limits, fire suppression type, flood exposure, security access, spare capacity or maintenance notification policy. The Versija/VERnet material describes a data centre in Riga and broad conditions such as uninterruptible power supply and climate control, but that describes Versija's offering, not necessarily the exact customer equipment or service boundary for Virtual Data Center Inc.

It also does not disclose whether any specific Virtual Data Center Inc workload has a separate power path or failover design.

A serious buyer should therefore request a service-specific dependency map. The map should identify the facility, room or cabinet type, power density, A/B power availability, generator runtime, cooling design, fire and water risk controls, carrier entry points, cross-connect provider, maintenance notice period and remote-hands service target. It should state whether the customer's service can survive a single PDU failure, a top-of-rack switch failure, an upstream router failure, a cooling unit failure or a facility access restriction.

If the company cannot provide that map, the buyer should treat the service as a single-site dependency until proven otherwise.

The same discipline applies to cloud-like product language. A virtual server is not inherently redundant. A virtual server is a workload on a physical host, storage layer, switch fabric and power chain. A "virtual data center" can be a resilient abstraction only if there are separate failure domains, replication, orchestration, capacity headroom and tested recovery. Public route evidence for AS199152 does not prove any of those features. It only proves a routeable edge.

Installed capacity is not usable capacity

The public route set can make capacity look larger than it is. Twenty-eight IPv6 prefixes and six IPv4 /24s sound substantial. They may support many services, but address capacity is not compute capacity. A provider can hold or announce address space while having limited racks, limited power, limited storage, limited support staff or limited demand. It can also have a small but well-run estate that is perfectly adequate for the customers it serves. Public sources do not show which is true.

Usable capacity is the amount that remains during stress. If one upstream drops, can the other carry all customer traffic without congestion? If a DDoS path is invoked, does it preserve the customer's application traffic or merely keep the route visible? If a host fails, is there spare compute ready for migration? If a storage node degrades, can backups restore fast enough to meet the customer's business recovery objective? If a rack loses one power feed, are all devices dual-corded and correctly balanced? If an engineer is needed on site, who can enter the room and how quickly?

The difference between installed and usable capacity is especially important when the public marketing surface is weak. A buyer cannot infer live inventory from a domain name or an ASN. It should ask for current service descriptions, not just historical screenshots or route tables. It should also distinguish between network services and hosted services. A network that can announce many prefixes may still rely on another company for server rooms and hands. A server room that can host equipment may still rely on a small set of upstream paths for internet reachability.

The RIPEstat routing-consistency view is a useful example. It showed several prefixes present in registry data but not in BGP at the checked time, while several IPv6 routes were in BGP without a matching registry route object in that view. That kind of difference is common in public routing data, but it is a reminder that registry entries, announced routes and customer service inventory are different layers. Capacity decisions should not collapse those layers into one simple claim.

For a customer, the practical test is not "does AS199152 exist?" The answer is yes. The test is "what portion of my workload can survive a named failure?" A buyer should make Virtual Data Center Inc answer that question for power loss, cooling loss, upstream loss, top-of-rack switch loss, host loss, storage loss, account access loss and maintenance. If the answer is plan-specific, the service order should say so.

Carrier diversity must be proven at the service edge

The public network evidence shows some diversity, but not enough to declare the customer edge resilient. RIPEstat observed two neighbours for AS199152. The aut-num record names four route-policy peers. BGP.tools shows AS8285 as an upstream. CAIDA's AS Rank shows a small customer cone and a modest degree. Those are all useful signals. They are not the same as a dual-carrier, dual-meet-me, dual-router design for a particular customer service.

Carrier diversity can fail quietly. Two upstreams may enter the same building through the same duct. Two logical sessions may terminate on one router. Two carriers may share a fibre provider. A DDoS mitigation provider may be available only when traffic is rerouted manually. A backup path may exist but be too small for peak traffic. A route-policy entity may still list a relationship that is dormant. Public BGP views can reveal some of these problems after an outage, but they cannot prove the private physical design before the outage.

For AS199152, customers should ask for a current upstream list and compare it with RIPEstat neighbours, routing consistency, BGP.tools and PeeringDB. If the provider says it has four upstreams but only two are visible, ask which two are active, which two are conditional, and whether any are used only for protected traffic. If the provider says it has DDoS protection, ask where the clean path enters the network and whether protected routes stay within AS199152 or move through another AS.

Customers should also verify route-origin hygiene. The RPKI results in this review are encouraging for most tested prefixes. Valid origin checks do not prevent every routing failure, but they reduce a major class of accidental or malicious origin problems. The one unknown IPv4 result, 194.8.6.0/24, should be discussed if a customer is assigned addresses from that block. The buyer should ask whether every assigned prefix has a current ROA, whether route filters match the intended origins, and whether there is monitoring for invalid or unexpected announcements.

Peering and transit also affect incident communication. If the customer sees loss through one region but not another, who owns the ticket? If AS8285 or AS212706 is the visible path, does Virtual Data Center Inc have direct escalation with those networks? If a prefix is announced through a DDoS path, does the customer's application have logs and contact information for mitigation decisions? The public record cannot answer those questions, which is why the service order should.

Who is affected when it fails

The impact of a failure depends on what customers actually buy. The public evidence does not show a current product catalogue, but the company name, route surface and data-centre category point to hosted-infrastructure use cases. The likely affected groups include server customers, VPS users, routed-prefix customers, DDoS-protected services, private network customers and organizations using the company's address space as part of a larger stack. Each group fails differently.

For a VPS or hosted-server customer, the main risks are host failure, storage failure, account portal loss, snapshot corruption, bandwidth congestion and support delay. If the service is tied to one physical host, the customer needs backup and rebuild plans. If storage is local to the host, a disk event can become data loss. If storage is shared, a storage event can affect many customers at once. If the account portal or billing system is unreachable, a customer may not be able to change service state during an incident.

For a customer using routed addresses or network services, the main risks are route withdrawal, RPKI invalidity, upstream loss, DDoS reroute failure, blackholing and contact escalation. A prefix can disappear while servers remain powered. A route can remain visible while packets are filtered or congested. A provider can have a valid origin but still carry traffic over a single fragile path. Monitoring needs to include routes, application reachability and packet loss from multiple places.

For a customer that has compliance or locality concerns, the main risk is not just downtime. It is uncertainty. The organization record is U.S.-registered. The prefix records and visible network context point strongly toward Latvia and the RIPE region. Historical public scan data also shows virtualdc-related hostnames associated with Russian-country networks in older observations, though those records do not prove the current service boundary. A customer needs a written answer for primary storage, backup storage, log storage, support access, legal entity, facility operator and incident jurisdiction.

The failure path is therefore not one path. It is a stack. Utility loss can take down a rack. Cooling loss can force a shutdown. A carrier meet issue can isolate routed services. A DDoS event can move traffic onto a constrained mitigation path. A website or support portal outage can delay escalation. A contract mismatch can leave the customer arguing over whether a failure is covered. Public evidence is enough to identify these risks; it is not enough to price them without provider answers.

Unofficial signals should stay in their lane

Unofficial market signals can be useful, but they must not carry more weight than they deserve. Aggregators such as BGP.tools, CAIDA AS Rank, and public routing pages are helpful because they bring route, ranking and relationship information into one place. Historical scan services such as urlscan.io searches for virtualdc.io can show that hostnames existed and resolved through certain networks at particular times. These signals can reveal patterns. They do not prove current operating capacity.

The most useful unofficial signals here are consistent with the official ones. AS199152 is active. Its route surface is not huge but is visible. The public records repeatedly point to Latvia-linked infrastructure. The company has no public PeeringDB profile. The main company domain was not a dependable source during this review. Those signals all support the same conclusion: the network exists, but current facility and service assurances need direct verification.

What unofficial signals cannot prove is equally important. They cannot prove that a cabinet has dual power. They cannot prove that backup generators have enough runtime. They cannot prove that a storage array has working replicas. They cannot prove that a customer can move workloads from one facility to another. They cannot prove that support has authority to fix a carrier issue. They cannot prove that a historical hostname still reflects current service.

The evidence that would settle the question is straightforward. Virtual Data Center Inc could publish or provide a current service description, facility list, upstream list, support policy, maintenance policy, RPKI/route-filtering policy, data-location statement and recovery design. It could show whether customer services are single-site, dual-site, replicated or manually rebuilt. It could state which services use AS199152, which use another network, and how DDoS traffic is handled. Until those answers are public or contractual, the prudent grade stays capped.

What to verify before relying on Virtual Data Center Inc

The first verification task is placement. Ask which facility hosts the ordered service, who operates that facility, whether the service is in a leased rack, provider-owned rack, virtual server pool, dedicated server, reseller environment or network-only arrangement. Ask whether the facility is in Latvia, the United States, another European country or a mix. Ask whether backups and logs are in the same location. The public evidence suggests a Latvia-heavy dependency, but the customer should not infer exact placement.

The second task is power and cooling. Ask for A/B power availability, generator runtime, UPS design, rack power limit, cooling redundancy, maintenance windows and recent single-feed exposure. If the service is virtual, ask which physical host and storage failure modes are covered by automatic migration. If the service is dedicated hardware, ask who replaces failed components and what spare inventory exists on site. If the provider relies on another facility, ask which obligations are passed through and which are controlled directly by Virtual Data Center Inc.

The third task is network diversity. Ask for current active upstreams, backup upstreams, exchange connections, route filtering, DDoS path and monitoring. Compare the answer with public data from RIPEstat neighbours, RIPEstat routing consistency, BGP.tools, PeeringDB for AS199152 and PeeringDB for AS8285. Any mismatch may have a good explanation, but it should have an explanation.

The fourth task is recovery testing. Ask what happens if an upstream session drops, if AS8285 is unavailable, if AS212706 is unavailable, if a route becomes RPKI-invalid, if one IPv4 /24 is filtered, if the customer portal fails, if a host dies, or if storage becomes inconsistent. Ask for tested restore time, not just backup existence. A customer should run its own restore test before treating the service as production-grade.

The fifth task is contract alignment. The service order should say what uptime covers, what it excludes, who communicates during incidents, where disputes are handled, whether maintenance is credited, how much notice is required, and what data export is available during termination. A hosted-infrastructure service is not just routers and servers. It is also billing, access, permissions, escalation, documentation and exit.

Monitoring should separate route health from service health

Customers that rely on Virtual Data Center Inc should monitor the service in layers. The first layer is public routing. Watch AS199152, the assigned prefix, the expected origin, the visible upstreams and the RPKI state. If a purchased address block is supposed to originate from AS199152, the customer should alert on origin change, disappearance, invalid RPKI state and sudden neighbour change. RIPEstat routing status, announced prefixes, BGP.tools and independent probes from multiple regions can all help. None of those checks should be treated as a complete service check.

The second layer is application reachability. A route can be visible while the customer's service is broken. A server can answer ping while the database is down. A website can load from one country while another path is blackholed. A protected route can stay up while mitigation rules break a game server, mail service or API. Customer monitoring should therefore test the actual protocol, the login path, the write path and the backup path from independent networks. If the customer uses both IPv4 and IPv6, both should be tested because RIPEstat showed a much larger IPv6 surface than IPv4 surface.

The third layer is facility symptom monitoring. Customers may not get direct access to the facility, but they can still watch for clues: simultaneous loss of several prefixes, long latency shifts through the same upstream, repeated packet loss during hot hours, support replies that mention remote hands, or maintenance notices that reference power work. Those clues do not prove the cause, but they help a customer ask sharper questions. If every incident appears to resolve only after a facility operator acts, the customer's true dependency is not just Virtual Data Center Inc's route policy. It is the facility and hands chain behind it.

The fourth layer is administrative independence. Keep domain registrar access, DNS control, payment contacts, emergency passwords and backup copies outside any service hosted on the same provider. If a hosted mail account is the only place outage notices arrive, the customer may lose the warning at the same time it loses the service. If the billing contact is unreachable, a payment issue can become an availability issue. If backups are stored only inside the same account, an account or portal outage can block recovery even when the data exists.

The final layer is exit testing. Before production use, export a workload, rebuild it elsewhere, and measure how long the process takes without privileged help from the provider. For a routed-prefix customer, test whether traffic can move to a different origin if contract terms allow it. For a VPS customer, test whether snapshots restore to a fresh environment. For a dedicated-server customer, test whether the application can be rebuilt from image, configuration and data backups. Public evidence for AS199152 is enough to justify monitoring. It is not enough to skip an exit rehearsal.

Evidence grade: Medium for routing, weak for facility assurance

Virtual Data Center Inc earns a capped Medium public evidence grade for the network and a weak grade for capacity assurance. The positive evidence is clear: AS199152 is registered to Virtual Data Center Inc in RIPE records, RIPEstat showed the AS announced on 2026-07-12, six IPv4 /24s and twenty-eight IPv6 prefixes were visible in the checked route view, most tested origins were RPKI valid, and secondary aggregators such as BGP.tools and CAIDA AS Rank corroborate a live AS199152 profile.

The limiting evidence is stronger than a normal caveat. The company did not provide a usable current public service page in the checks for this article. AS199152 did not have a public PeeringDB profile. The visible physical clues point mainly to Latvia-linked infrastructure and upstreams rather than a clearly documented U.S. data-centre estate. The route-policy record names more peers than were observed in BGP at the checked time.

The public record does not show rack count, facility contract, dual utility feed, generator runtime, cooling redundancy, cross-connect diversity, spare hardware, service-level terms, customer failover, backup restore tests or support escalation.

The practical conclusion is precise. Virtual Data Center Inc is a real routing subject with enough public network evidence to deserve monitoring. It is not publicly proven as a resilient data-centre capacity provider. Any customer relying on the company should demand the exact facility map, power map, route map and recovery map before placing important workloads. Until then, marketed capacity should be treated as a hypothesis and tested as if a single facility, single upstream or single operations team could still be the limiting point.