NIXI-CSC Data center has to prove whether marketed data-centre capacity can survive power and carrier constraints

Summary

• NIXI-CSC Data center has stronger public network evidence than a purely speculative data-centre announcement. APNIC and RIPEstat identify AS149600 as NIXI-AS-IN, described as NIXI-CSC Data center, and RIPEstat showed the ASN announced on 2026-07-12.
• The hard current routing surface is modest but real: seven IPv4 /24 prefixes, 1,792 IPv4 addresses, no visible IPv6 announcement, and five observed BGP neighbours in the RIPEstat capture used here.
• The public facility record is procurement-heavy. NIXI-CSC tender documents for Tripura State Data Centre at Agartala refer to active IT infrastructure, non-computing infrastructure, final acceptance testing, 99.8% uptime language, and revamping toward an 80-plus-rack solution.
• The biggest evidence gap is not the ASN. It is the physical operating proof: dual utility feeds, generator runtime, cooling redundancy, meet-me-room design, fibre entrance diversity, fire suppression performance, maintenance procedures and actual customer failover evidence.
• The evidence grade is Medium. AS149600 is live and cross-checkable, but public evidence still does not prove that the marketed data-centre capacity is installed, fully usable, independently powered, carrier-diverse and tested under fault.

The route exists; the resilience claim still has to be earned

NIXI-CSC Data center is not an empty label in a spreadsheet. The APNIC RDAP autonomous-system record identifies AS149600 as NIXI-AS-IN in India, and RIPEstat's AS overview describes the holder as NIXI-AS-IN - NIXI-CSC Data center. In the 2026-07-12 routing-status view, RIPEstat showed AS149600 as announced, with 325 of 325 IPv4 RIS peers seeing it and no IPv6 visibility.

That is the good news. A visible ASN makes the company easier to monitor than a data-centre claim with no public network edge at all. It means there is a current route surface that customers, peers and analysts can test. It also lets the article avoid a weak form of speculation: the question is not whether there is any public network sign. There is.

The harder question is whether that sign maps to dependable data-centre capacity. A data centre is a physical bargain. Customers hand over trust because the operator says the rack, power feed, cooling loop, remote hands, access path, firewall, switch, router and carrier interconnect will stay coordinated. BGP can show public reachability. It cannot show whether a generator transfer was tested, whether two carriers enter by separate ducts, whether the same cooling plant covers every rack row, or whether a support engineer can reach the site during a regional disruption.

For NIXI-CSC Data center, the operating story therefore has two halves. The first half is a live AS149600 internet edge. The second half is the Tripura State Data Centre and data-centre procurement trail. The article should not collapse one into the other. A route can be real while the facility story remains incomplete. A tender can be specific while production proof remains private. The gap between those two facts is where the risk sits.

Agartala is the physical centre of the public record

The most specific public facility evidence is tied to Tripura State Data Centre at Agartala. NIXI tender files include an IT infrastructure tender for Tripura State Data Center at Agartala and a non-IT infrastructure RFP for the same site. Both documents describe the issuer as NIXI-CSC Data Services Ltd, and both frame the work around the Tripura State Data Centre rather than a generic cloud brand.

The IT tender says Tripura had set up a state data centre in Agartala to support e-governance work and that the state planned to revamp the facility to reach an 80-plus-rack solution. It also identifies the active-IT scope as supply, installation, commissioning and integration for the data centre. The table of contents points to data-centre networking, firewalls, load balancer and WAF, WAN routers and structured cabling. Those are not decorative features. They are the control surface through which workloads, departments and administrators would experience an outage.

The non-IT RFP is just as important because data centres fail in the parts buyers do not see. It covers diesel generators, UPS and batteries, racks, cable runners, bus bar track, VESDA, addressable fire alarm systems, gas-based fire suppression and data-centre infrastructure management. A later corrigendum records a design discussion around 76 server-room racks, two telecom racks and two staging-room racks, with a 10 kW per rack assumption and full-capacity busway sizing around an 800 kW server-hall load.

Those tender details make the subject more serious. They also make it easier to audit. Once a public document introduces rack count, power density, uptime language and active infrastructure, the operator has invited a practical question: which of those design assumptions became installed, tested and operational capacity?

The public-sector context raises the consequence of failure

Tripura State Data Centre is not a neutral colocation label. The tenders frame it around e-governance, state services and a government data-centre role. Public reports also described Tripura's 2022 collaboration with NIXI-CSC as a move to set up a data centre in the state, with the Economic Times Government, Northeast Today and Devdiscourse all covering the announcement.

The importance of that context is not promotional. It changes the harm model. If a small commercial hosting site fails, the first visible harm may be a store, a portal or a reseller losing service. If a state data-centre environment fails, the affected systems can include citizen services, departmental applications, authentication paths, data exchange between agencies, municipal platforms and administrative dashboards. Even when individual workloads are not named publicly, the class of dependency is clear.

Tripura's own policy environment underlines the same point. The Tripura Data Centre Policy, 2021 and the state policies page show the government trying to attract data-centre investment through incentives that include power and connectivity themes. A public information note on the policy says the state wanted to encourage IT and IT-enabled enterprises, support data-centre companies and provide measures such as low-cost electricity, dual-grid power and internet-use subsidy.

Policy support is useful, but it is not an uptime guarantee. A data centre can receive an incentive and still be constrained by last-mile grid resilience, spare-parts logistics, carrier diversity, seasonal heat, water availability, staffing and permitting. The policy tells readers why Tripura wants the asset. It does not prove that every NIXI-CSC service running through the asset will survive the first bad hour.

The 80-plus-rack ambition should be read as a question

The rack number is the temptation in this story. Eighty-plus racks sounds concrete enough to quote as capacity. The safer reading is more careful. In the tender trail, 80-plus racks is an intended revamp or design direction, not a public proof of currently sold, powered and resilient capacity. The corrigendum discussion around 76 server-room racks, two telecom racks and two staging racks makes the engineering envelope more visible, but it does not publish a commissioning certificate, utilization report, power-availability certificate or failover-exercise result.

Installed capacity, usable capacity and recoverable capacity are three different things. Installed capacity is what the site can house on paper or after a build-out. Usable capacity is what can be powered, cooled, connected and safely operated under normal load. Recoverable capacity is what still works when one feed, one UPS path, one cooling unit, one telecom rack, one route or one maintenance team is unavailable.

If the design assumption is 10 kW per rack, the operating burden is not only the IT load. Cooling, UPS losses, power distribution, monitoring, lighting, security, fire systems and support rooms also draw from the same physical environment. A buyer should not ask only how many cabinets can fit. It should ask which rack rows are powered by which UPS strings, which busway segments are backed by which generator, which cooling units cover which heat load, and whether the remaining system can carry critical load during maintenance.

The same logic applies to the telecom racks. A data centre can hold dozens of server cabinets and still have a fragile external path if the meet-me function is thin. Two telecom racks may be adequate for a tightly scoped public-sector environment, or they may become a bottleneck if the site is marketed as a broader regional infrastructure node. The evidence needed to decide between those readings is not a rack count. It is a carrier map, cross-connect policy, diversity diagram and incident history.

AS149600 gives the public edge a useful shape

The live network layer is the strongest part of the public evidence. RIPEstat announced prefixes showed seven current IPv4 /24s for AS149600 in the 2026-06-28 to 2026-07-12 window: 45.250.3.0/24, 45.250.0.0/24, 103.219.11.0/24, 45.250.1.0/24, 45.250.2.0/24, 45.249.241.0/24 and 103.219.8.0/24. IPinfo independently lists NIXI-CSC Data center, 1,792 IPv4 addresses, no IPv6 addresses, 27 hosted domains and an ASN type of Hosting. BGP.tools also shows an active APNIC-allocated network with seven IPv4 originated prefixes and no IPv6 originated prefixes.

That is enough to say the entity is not merely a dormant corporate label. It has reachable public address space. IPinfo's traceroute and pingable-IP observations also suggest externally testable endpoints, including pings from Indian measurement locations. Those are useful operating signals, especially because they come from independent public routing and measurement services rather than from a sales brochure.

Still, the shape of the edge is modest. Seven /24s provide 1,792 IPv4 addresses, not hyperscale address space. That can be perfectly adequate for a state data-centre function, an infrastructure gateway, management services, customer workloads or a mix of public-sector applications. But it should not be oversold as broad national cloud capacity. The public edge tells us that some services are visible. It does not tell us how many tenants exist, how many racks are live, how much load is protected, or whether workloads can move during a facility event.

The absence of visible IPv6 is also not fatal, but it matters. For a data-centre operator associated with NIXI and public digital infrastructure, no public IPv6 announcement in the RIPEstat and BGP.tools captures is a gap to explain. It may reflect the current workload mix, the stage of deployment or an operational choice. It may also mean customers who expect dual-stack hosting or future public-sector IPv6 readiness should ask for a roadmap rather than assuming it exists.

Carrier evidence is promising, but diversity is not the same as names

RIPEstat's ASN-neighbours view showed five observed neighbours for AS149600 on 2026-07-12: AS132215, AS132717, AS45820, AS55836 and AS9730. RIPEstat's AS overview resolves those holders as Powergrid Teleservices, NxtGen Datacenter & Cloud Technologies, Tata Teleservices ISP, Reliance Jio Infocomm and Bharti Telesonic. IPinfo and BGP.tools label the same set as peers or upstreams.

That list is encouraging because it includes recognizable Indian telecom, power-grid telecom and data-centre/cloud names. A single-homed data-centre network would be easier to criticize. NIXI-CSC's public routing surface looks more robust than that. Multiple observed neighbours mean the edge has more than one visible route relationship.

The caution is physical. BGP diversity is not necessarily fibre diversity. Two carriers can enter the same building through the same duct, terminate in the same meet-me area, rely on the same campus power path, or concentrate on one router pair. Two logical upstreams can share metro transport risk. An observed neighbour can also be route-server, paid transit, private interconnect, backup transit or a temporary path; the public view does not disclose the commercial contract or the cable route.

The procurement question is therefore precise: can NIXI-CSC show that at least two carrier paths enter through physically separate routes, land on separately powered equipment, and have enough committed capacity to carry priority services when the primary path is unavailable? The answer may be yes. The public record does not show it. Until it does, the carrier story should be graded as evidence of route diversity, not proof of end-to-end resilience.

A carrier-meet interruption would test the whole facility

The most useful way to read the five-neighbour routing evidence is through a failure scenario. Suppose one carrier path disappears during a maintenance window or fibre fault. If AS149600's routing policy is healthy, the remaining neighbours should continue to announce reachable paths. But the facility impact depends on much more than the route table. It depends on where the failed circuit enters the building, which router or telecom rack carries it, whether the alternate carrier uses a different cable tray and whether customer traffic can shift without overrunning the remaining commit.

The telecom-rack detail in the tender clarifications is therefore not minor. Server racks draw attention because they look like capacity. Telecom racks decide whether that capacity can be reached. If a meet-me rack, cross-connect panel, optical shelf or edge router becomes unavailable, a data hall full of powered servers can still become an island. That is the uncomfortable part of data-centre resilience: the cheapest-looking bottleneck can control the most expensive asset.

A credible carrier design would separate failure domains at several levels. First, the carrier contracts should not all depend on one commercial counterparty or one upstream family. Second, the fibres should take separate physical paths into the building or campus. Third, the cross-connects should terminate in separately powered and protected network equipment. Fourth, the BGP policy should be tested so routes converge without human improvisation. Fifth, the remaining path should have enough capacity for priority services, not merely enough for a quiet-hour heartbeat.

Those details are not visible in RIPEstat neighbours, IPinfo or BGP.tools. The public services can show that the AS has observed relationships with Tata Teleservices, Reliance Jio, Bharti Telesonic, Powergrid Teleservices and NxtGen Datacenter & Cloud Technologies. They cannot show whether two paths share civil works outside Agartala, whether a single maintenance vendor controls the meet-me work, or whether one device reboot would remove more than one apparent route option.

That is why the article treats the carrier list as a positive signal and still asks for failover evidence. In a government-service context, a carrier failover is not complete when BGP reconverges somewhere on the internet. It is complete when users can still reach the relevant application, administrators can still manage the service, monitoring still sees the right symptoms, and the operator can explain exactly which link failed and which one absorbed the load.

PeeringDB silence removes one layer of transparency

The PeeringDB query for AS149600 returned no network entity. That does not mean the network is not interconnected. PeeringDB is voluntary and operator-maintained. Many real networks lack a public profile, and some networks publish profiles that lag reality.

For this article, the absence matters because it removes a useful disclosure layer. A PeeringDB profile can show exchange presence, facility listings, peering policy, traffic ratio, NOC contacts and approximate prefix count. Those fields do not certify resilience, but they help a buyer ask better questions. Without them, readers have to lean more heavily on route collectors, IPinfo, BGP.tools, Hurricane Electric and direct operator disclosure.

NIXI's wider public role makes that absence more noticeable. NIXI is associated with internet exchange and number-resource functions, and a NIXI data-centre tender for upcoming internet exchanges describes NIXI's peering mission and data-centre requirements for exchange expansion. If the NIXI-CSC site is intended to support broader exchange, government or regional connectivity use, a public interconnection profile would make the operating model easier to inspect.

But the article should not punish the company for a missing directory entry. The correct conclusion is narrower: public peering and facility disclosures are thinner than the route table. That is a transparency gap, not a finding of failure.

RPKI is partly reassuring and partly unfinished

Route-origin validation is one of the places where AS149600 looks better than many small infrastructure networks. In the RIPEstat RPKI tests used here, the five 45.x /24 prefixes returned valid status for AS149600. The two 103.219.x /24 prefixes tested as unknown. IPinfo's page similarly marks the 45.x ranges as RPKI valid while listing the 103.219.8.0/24 and 103.219.11.0/24 ranges without the same visible valid badge.

That split matters. Valid ROAs reduce the chance that networks enforcing route-origin validation will reject a legitimate origin for those prefixes. Unknown status is not the same as invalid; it means the public validation path did not find a covering ROA for the tested prefix-origin pair. But for a public-sector-adjacent data-centre network, the better target is consistent route-origin authorization across all live production prefixes.

RPKI does not prove facility resilience. It does not say whether a UPS worked, whether a router has a redundant supervisor, whether a cable cut was diverse, or whether customer applications have failover. But it does show administrative routing hygiene. A mixed result should become an operating task: make every production prefix easy to validate, publish route objects where appropriate, monitor invalid or unknown drift, and rehearse what happens when an upstream applies stricter filters.

In a network that appears to originate only seven /24s, the audit burden is not large. That makes the unevenness more visible. The operator can reasonably be expected to keep the whole public prefix set clean.

Power is the first capacity constraint, not a back-office detail

The planned power envelope is the heart of the risk. The non-IT tender and corrigenda point to UPS, batteries, diesel generation, bus bar track and rack power density. Tripura's data-centre policy also treats power as a strategic incentive, including references to low-price electricity and dual-grid supply in public policy summaries. Those details are not administrative. They decide whether the site can turn advertised racks into dependable service.

For a data-centre buyer, the minimum evidence set is straightforward. Which utility feeds serve the site? Are they independent at the substation and route level? What UPS topology is used? What is the generator runtime at design load and at current load? How quickly is fuel replenished during a regional disruption? Which rack rows are protected by which power paths? Can one UPS module or power-distribution segment be maintained without reducing protected capacity below the customer commitment?

The 10 kW-per-rack assumption in the corrigendum is helpful because it gives an order of magnitude. It also raises the stakes. A server hall designed around hundreds of kilowatts cannot be evaluated like a small office server room. Heat rejection, breaker coordination, fuel logistics, spares and operations training all become part of the service.

The public record does not provide a measured load curve, generator test report or utility reliability history. That absence is normal for sensitive infrastructure, but it means buyers should not accept "data centre" as a power assurance label. The operator should show evidence under confidentiality if it cannot publish it: commissioning results, black-start tests, monthly generator run logs, fuel contracts, maintenance exceptions and incident postmortems.

Cooling turns rack density into an operating limit

Cooling is the second capacity constraint. A rack can be installed before it can be safely used. At 10 kW per rack, cooling design and airflow discipline decide whether every cabinet can run at intended density or whether the site has to derate some rows. The CEEW study on India's data-centre ecosystem is useful context here because it frames data centres as power and water infrastructure, not only digital infrastructure. It also notes India's fast-growing capacity and the importance of cooling choices as the sector scales.

For NIXI-CSC Data center, the tender trail mentions precision air-conditioning context through PAC discussion and a request around achieving N+1 configuration by using existing units plus additions. That is a design conversation, not a public certificate. It tells readers what kind of question the project had to answer: can the cooling plant cover the planned rack load with one component down?

Cooling resilience is not only the number of units. It is the combination of airflow containment, hot-spot monitoring, set points, maintenance windows, water-leak detection, spare parts, compressor or chilled-water resilience, and the authority to reduce load before heat damages equipment. A site can have redundant cooling on paper but still fail if a sensor is wrong, filters are neglected, airflow is blocked or the maintenance plan requires shutting down too much capacity at once.

The failure path is easy to imagine. A utility event forces a power transfer. Some cooling equipment restarts slowly. A server row heats faster than expected. Network equipment in a telecom rack is more sensitive than assumed. Operators then have to decide which services to shed and which customers to notify. A public data-centre claim is credible only if that decision tree has been rehearsed.

Fire, security and monitoring are not generic compliance boxes

The non-IT RFP's references to VESDA, addressable fire alarms, gas suppression and data-centre infrastructure management are useful because they acknowledge the facility as a monitored environment. Fire protection and monitoring are not ceremonial in a data centre. They are the difference between a small incident and a long outage.

A VESDA system can detect smoke early, but early warning matters only if response procedures are clear. Gas suppression can protect equipment, but only if room integrity, detection logic, interlocks and staff training are correct. DCIM can show capacity and environmental conditions, but only if it is kept current and monitored by people who can act. Security controls protect the building, but they can also slow emergency access if procedures are clumsy.

The public evidence does not show the final installed system, inspection records or live monitoring dashboard. It should not. Those details can be sensitive. But a buyer or government stakeholder can still ask for controlled proof. The operator should be able to show commissioning dates, annual test history, alarm escalation paths, sensor coverage, suppression-zone maps and recent maintenance exceptions.

This is where a data-centre procurement file can be both reassuring and incomplete. It proves the buyer knew which systems belonged in scope. It does not prove those systems were installed to the intended standard, maintained after handover or tested during a real incident.

Public routing history shows continuity, with some unevenness

The route-history record helps separate a current network from a newly staged claim. RIPEstat routing history traces AS149600 visibility back to 2022, with 45.249.241.0/24 first appearing in May 2022. The current announced-prefixes view shows seven IPv4 /24s active in the most recent window. That pattern supports the view that AS149600 has been part of the operating surface for several years.

History also shows that the prefix set has changed. Some historically visible ranges do not appear in the current RIPEstat announced-prefixes list, while the seven current prefixes are stable in the recent capture window. That is not automatically bad. Operators renumber, change product placement, retire ranges, move workloads and adjust routing policy. But every change matters if customers depend on stable public addresses or if government services need predictable access lists.

The buyer's question is not whether a route ever disappeared. It is whether changes were planned, notified and reversible. Did the operator maintain a customer-impact map? Were routes withdrawn during maintenance? Were any services moved from one prefix to another? Did RPKI records, DNS, firewall rules and monitoring follow the change? Route history is an audit signal, not an accusation.

The fact that AS149600 has multiple years of visibility is positive. The fact that public history alone cannot explain the service impact of route changes is the evidence boundary.

The region makes carrier and repair paths part of the story

Agartala is not Mumbai or Chennai. That does not make it a bad data-centre location. It changes the dependency map. A northeastern Indian state data-centre site may be valuable precisely because it brings digital infrastructure closer to users, departments and regional services that should not depend entirely on faraway metro clusters. It can support lower administrative latency, local digital capability and regional investment.

The same geography makes resilience proof more important. Carrier diversity, equipment spares, skilled remote hands, diesel supply, grid stability and physical access during weather or civil disruption may not look like they do in India's largest data-centre markets. If the site is positioned as a regional gateway or public-service platform, its recovery path must be tailored to local constraints rather than borrowed from a metro colocation brochure.

The Tripura Department of IT policies page and the Tripura Data Centre Policy show that the state is trying to make data-centre investment part of the local economy. That is a legitimate development aim. It also means operational evidence should be specific to the state. "Dual grid" should mean identifiable supply arrangements. "Internet subsidy" should not distract from carrier diversity. "Data-centre hub" should not be a substitute for route, power and cooling tests.

Regional infrastructure succeeds when it is honest about locality. A well-run smaller site with clear failover and realistic capacity can be more valuable than a larger claim that hides weak recovery paths. NIXI-CSC Data center should be assessed on the former standard.

Who is affected when it fails

The direct users of NIXI-CSC Data center are not fully visible in public data. IPinfo's hosted-domain count and pingable-IP observations suggest live services, but they do not identify every workload or tenant. The Tripura SDC context suggests a public-sector dependency class, but public tender files do not list every application or department that would suffer during an incident.

That uncertainty should not lead to indifference. If AS149600 or the facility edge fails, the affected parties may include government administrators, citizens using online services, local agencies, domain operators, network staff, software vendors, contractors, monitoring systems and downstream users who do not know NIXI-CSC sits in their path. Public-sector infrastructure often fails sideways: a portal may be online but authentication may break; a database may be safe but the network path may be unavailable; a department may have data but no usable access channel.

The failure can also spread through support. If a data-centre incident affects the management network, the ticket portal, remote access or the monitoring system, repair can become slower exactly when speed matters most. That is why support channels and out-of-band access belong in a resilience review. They are part of the infrastructure, not an administrative afterthought.

For customers or government stakeholders, the operational test should be phrased in user terms. Which services remain reachable if one carrier drops? Which services survive a power transfer? Which users are notified first? Which applications have recovery-time and recovery-point commitments? Which systems can be shed to protect the most critical workloads? The public route table cannot answer those questions, but it shows where to start.

What NIXI-CSC should disclose to turn Medium into Strong

The path from Medium evidence to Strong evidence is not mysterious. First, NIXI-CSC should show the current facility state: commissioned rack count, usable powered capacity, cooling topology, generator and UPS design, fire-system commissioning and DCIM monitoring scope. It does not have to publish every sensitive diagram, but it should be able to provide controlled evidence to serious customers and public stakeholders.

Second, it should separate design capacity from sold or protected capacity. If 80-plus racks is the build-out target, readers need to know how many are installed, how many are powered, how many are cooled at design density, how many are reserved for government workloads, and how many have redundant carrier access. A rack that exists but cannot be powered or cooled at intended density during a failure is not the same asset as a rack with tested recoverable load.

Third, it should publish or privately evidence the carrier model. The public route table shows five observed neighbours; the operator should map those to actual transit, peering or backup roles. It should identify whether paths are physically diverse, whether any two share metro transport, whether the site has separate meet-me entrances, and what happens if one telecom rack or one carrier fails.

Fourth, it should complete the routing hygiene picture. The five 45.x prefixes appear RPKI valid in the checks used here, while the two 103.219.x prefixes were unknown. Consistent RPKI coverage, route-object maintenance and change monitoring would reduce avoidable control-plane risk.

Finally, it should share failover evidence. The most persuasive document is not a marketing claim. It is a recent exercise report: date, scenario, systems affected, recovery time, data-loss outcome, carrier behavior, generator behavior, cooling behavior, customer communication and lessons fixed. That is how an announced route and a tendered facility become trusted infrastructure.

How buyers should test the claim

A buyer should begin with the public network edge. Compare the operator's list of production prefixes with RIPEstat announced prefixes, BGP.tools, Hurricane Electric, IPinfo and Cloudflare Radar. Ask which prefixes carry production customer traffic, management traffic, public-sector workloads, test systems or spare capacity. Do not accept an ASN as a proxy for all service delivery.

Next, ask for facility proof. The questions should follow the public tender trail: racks, UPS, batteries, diesel generation, bus bar track, fire detection, fire suppression, monitoring, WAN routers, firewalls, load balancers and structured cabling. The answer should include current status, not only procurement scope. A procurement item that was specified in 2022 is not automatically healthy in 2026.

Then test the carrier story. Ask whether the five observed neighbours are current upstreams, peers or route-server paths. Ask which are primary and which are backup. Ask whether two can carry critical load together, whether any path shares a duct or meet-me rack, and how maintenance is coordinated. If the site supports state services, ask how carrier failure is communicated to agencies and whether critical users have an alternate access path.

Finally, insist on an exit and continuity plan. If NIXI-CSC Data center becomes unavailable, how are backups reached? Which DNS changes are needed? Can workloads be moved to another site? Does the operator provide public status, customer-specific incident reports and data export procedures? The strongest infrastructure providers can answer those questions before the failure.

The evidence grade

NIXI-CSC Data center earns a Medium evidence grade. The network evidence is meaningfully stronger than the directory snapshot's thin-footprint warning would imply: APNIC, RIPEstat, IPinfo, BGP.tools and Hurricane Electric all support a live AS149600 public routing surface, with seven IPv4 /24s and five observed neighbour or upstream relationships. That gives readers a real operating edge to monitor.

The data-centre evidence is more cautious. The NIXI-CSC tender trail supports an Agartala Tripura State Data Centre revamp, active IT and non-IT infrastructure scope, 99.8% uptime language, 80-plus-rack ambition and detailed power, cooling, rack and monitoring concerns. It does not publish current installed capacity, audited usable capacity, generator runtime, dual-utility proof, carrier-entrance drawings, customer workload inventory or actual failover results.

That combination is neither Weak nor Strong. It is Medium because there is a real public network and a specific facility procurement trail, but the central resilience question remains open. NIXI-CSC Data center can be operationally important and still need to prove that marketed data-centre capacity survives power, cooling and carrier constraints.

The practical conclusion is simple: treat AS149600 as live, treat the Tripura State Data Centre documents as serious but not self-proving, and require fault evidence before accepting any claim of resilient data-centre capacity. In infrastructure, the route is where the story becomes visible. The power room, cooling plant and carrier entrance are where the story becomes true.