What is CTGNet / CN2 GIA? China Telecom AS4809 and AS23764 explained

Many VPS providers advertise “CN2,” “CN2 GIA,” or “China Telecom optimized.” The label is easy to print on a product page. The path is harder to fake.

For China Telecom users, the useful question is whether traffic uses the premium China Telecom route in both directions: the China Telecom access network, the CN2/AS4809 premium segment, the current CTGNet/AS23764 international delivery path, and then the VPS provider network.

For Riven Cloud Tokyo, the optimized China Telecom path is:

China Telecom access network / AS4134
-> CN2 premium segment / AS4809 / 59.43
-> CTGNet international edge / AS23764
-> Riven Cloud Tokyo / AS3258

That is materially different from a normal international transit path such as:

China Telecom AS4134
-> SoftBank AS17676
-> Riven Cloud Tokyo / AS3258

The MTR samples in this article were collected on June 29, 2026. They are short samples, not an SLA. They are useful because they show both the visible AS path and the final-hop behavior for the optimized China Telecom route, then compare it with a standard SoftBank transit baseline from the same test set.

China Telecom routing has several moving parts

China Telecom routing is easy to oversimplify because several related names show up in the same conversation.

China Telecom’s Global Internet Access page says the service offers access to ChinaNet (AS4134) and CN2 (AS4809). Public PeeringDB records list CTGNet as AS23764 with the IRR as-set AS-CTGNET, and China Telecom / CN2 as AS4809 with the IRR as-set AS-CN2.

For VPS buyers, the practical map looks like this:

AS4134: ChinaNet / China Telecom’s large public Internet backbone and access network.
AS4809: CN2 / China Telecom’s premium backbone segment, commonly associated with CN2 GIA in the VPS market.
AS23764: CTGNet / China Telecom Global’s international network used for peering and international delivery.

A China Telecom broadband user may begin in AS4134 or a regional access network. A premium route should move the traffic into the CN2/AS4809 segment and then use CTGNet/AS23764 for the international handoff.

That last point is where many route descriptions get sloppy. CTGNet and CN2 GIA are related in how customers experience the route, but they are not interchangeable terms.

What CN2 GIA means in practice

CN2 GIA is market shorthand for China Telecom’s premium global Internet access route. VPS buyers usually associate it with the CN2/AS4809 backbone, lower latency, less congestion, and more predictable cross-border performance than ordinary ChinaNet routes.

The label alone does not prove much. A useful route check asks two questions:

Does the route show the premium CN2 segment, often visible as 59.43 hops or AS4809?
Does the international handoff avoid ordinary transit and land on the intended China Telecom Global path?

In practice, customers should look less at the label and more at the path. A trace that says “CN2” somewhere in the middle is weaker evidence than a clean path showing China Telecom access, CN2/AS4809, CTGNet/AS23764, and the provider network in both directions.

What CTGNet means in this route

CTGNet is the China Telecom Global international network associated with AS23764. In the Riven Cloud Tokyo route, CTGNet is the peer-facing international side of the China Telecom path.

CN2/AS4809 is the premium China Telecom segment that mainland China users have historically associated with CN2 GIA. CTGNet/AS23764 is the international delivery and interconnection side used in the current route.

Riven Cloud peers with China Telecom through CTGNet / AS23764. China Telecom traffic from mainland China uses the CN2 / AS4809 premium segment before reaching CTGNet / AS23764, where it is handed to Riven Cloud’s Tokyo network on AS3258. PeeringDB lists AS3258 as xTom Tokyo, which matches the Tokyo network context for this service.

The clean shorthand is:

AS4134 access
-> CN2 / AS4809 / 59.43
-> CTGNet / AS23764
-> Riven Cloud Tokyo / AS3258

The Riven Cloud China Telecom path

The optimized path from a China Telecom user to Riven Cloud Tokyo should show the China Telecom access side first, then the premium CN2 segment, then CTGNet, then the Riven Cloud endpoint.

China Telecom user
-> China Telecom access network / AS4134
-> CN2 premium segment / AS4809 / 59.43
-> CTGNet international edge / AS23764
-> Riven Cloud Tokyo / AS3258

Each part has a job:

AS4134 is where many ordinary China Telecom users begin.
The 59.43 hops indicate the CN2 premium segment.
CTGNet / AS23764 is the international handoff and China Telecom peer path.
AS3258 is the Tokyo network used by the Riven Cloud test node.

The reverse direction matters as much as the forward direction. A route can look good from China to Tokyo and still return through a different, less suitable path. The Riven Cloud sample below showed the expected CTGNet and CN2 path in both directions.

Optimized route MTR sample

The optimized MTR samples were collected on June 29, 2026 at 2026-06-29T10:22:04+0000 for mainland China to Tokyo and 2026-06-29T10:23:28+0000 for Tokyo to mainland China. Each sample used 10 probes.

The raw output showed China Telecom AS4134 near the access side, multiple 59.43 hops on the CN2 segment, CTGNet hostnames such as ct163.jp.tyo.ctgnet and jp.tyo.ctgnet, and the final Riven Cloud Tokyo endpoint on AS3258.

Direction	Visible premium path	Final-hop avg RTT	Best RTT	Final-hop packet loss
Mainland China to Tokyo	AS4134 -> CN2/59.43/AS4809 -> CTGNet/AS23764 -> AS3258	36.3 ms	36.1 ms	0.0%
Tokyo to mainland China	AS3258 -> CTGNet/AS23764 -> CN2/59.43/AS4809 -> AS4134	41.6 ms	41.6 ms	0.0%

The optimized route shows the expected premium China Telecom path in both directions. Traffic does not simply exit China Telecom through ordinary international transit. It uses the CN2/59.43 segment and CTGNet/AS23764 before reaching the Riven Cloud Tokyo network.

Standard SoftBank transit comparison

SoftBank is a normal international transit path. PeeringDB lists SoftBank Corp. as AS17676. There is nothing inherently wrong with using SoftBank for general Internet traffic.

For this China Telecom to Tokyo comparison, the baseline path was less suitable:

China Telecom user
-> China Telecom AS4134
-> SoftBank AS17676
-> Riven Cloud Tokyo / AS3258

The standard transit baseline from the same June 29, 2026 test set showed higher final-hop RTT than the CTGNet/CN2 optimized path.

Direction	Standard transit path	Final-hop avg RTT	Best RTT	Final-hop packet loss
Mainland China to Tokyo	AS4134 -> SoftBank/AS17676 -> AS3258	78.1 ms	69.6 ms	30.0% in this short sample
Tokyo to mainland China	AS3258 -> SoftBank/AS17676 -> AS4134	74.1 ms	63.1 ms	10.0% in this short sample

This sample does not prove that SoftBank is bad. It shows the difference between a generic international transit path and a China Telecom matched premium path for this specific Tokyo VPS use case.

Side-by-side results

The RTT gap was large in both directions.

Direction	Standard transit avg RTT	CTGNet/CN2 optimized avg RTT	Reduction	Optimized path
Mainland China to Tokyo	78.1 ms	36.3 ms	41.8 ms lower / about 54% lower	CN2/AS4809 -> CTGNet/AS23764
Tokyo to mainland China	74.1 ms	41.6 ms	32.5 ms lower / about 44% lower	CTGNet/AS23764 -> CN2/AS4809

In this sample, the CTGNet/CN2 optimized route reduced average RTT by more than 40 ms in the China-to-Tokyo direction and more than 30 ms in the return direction. The path itself is the more important signal: the optimized route used the intended China Telecom premium network instead of ordinary international transit.

That route choice is what customers should evaluate when they compare CN2 GIA VPS offers. A low number in one ping test is useful. A clean premium carrier path in both directions is better evidence.

What customers feel

Most customers do not buy AS paths for their own sake. They care whether a server feels usable from mainland China.

For China Telecom users, a better matched route can show up in practical ways:

SSH sessions feel more responsive.
Control panels and dashboards spend less time waiting on the network.
API calls from mainland China have lower round-trip delay.
Websites load faster for China Telecom users.
Real-time applications have less room for jitter to become visible.
Evening peak is less likely to be dominated by ordinary international transit congestion.

The word “likely” matters. Route optimization improves the path. It does not make every application fast, and it does not remove every local access problem.

How to read MTR without fooling yourself

MTR is useful, but it is easy to overread.

Focus on the final destination, the overall RTT pattern, and the visible AS path. Intermediate packet loss can be caused by ICMP rate limiting, router control-plane protection, or devices that simply do not answer probes. A 100% non-response on an intermediate hop does not prove end-to-end loss when later hops and the final destination still respond normally.

For this comparison, the important checks are:

Final-hop average RTT.
Final-hop packet loss.
Whether the visible path uses CN2/59.43/AS4809.
Whether the international handoff uses CTGNet/AS23764.
Whether the return path also uses the premium China Telecom route.

Short MTR samples are useful route evidence. They are not a guarantee for every province, every hour, or every future carrier policy change.

What CTGNet/CN2 cannot guarantee

Premium China Telecom routing gives traffic a better path. It does not suspend the laws of the Internet.

Performance can still depend on the user’s province, local access network, time of day, submarine cable events, carrier routing changes, firewall behavior, application protocol, customer-side Wi-Fi, and last-mile conditions.

A clean CTGNet/CN2 path reduces dependence on ordinary international transit. It cannot control every hop before the user reaches China Telecom’s backbone, and it cannot guarantee that every application will use the network efficiently.

Treat route optimization as one important part of a deployment decision, alongside CPU, RAM, NVMe storage, transfer quota, backup policy, and application design.

Conclusion

For China Telecom users, Riven Cloud’s optimized Tokyo route is built around the premium China Telecom path:

AS4134 access network
-> CN2 / AS4809 premium segment
-> CTGNet / AS23764 international delivery
-> Riven Cloud Tokyo / AS3258

The June 29, 2026 sample showed much lower average RTT than ordinary SoftBank transit in both directions: 36.3 ms versus 78.1 ms from mainland China to Tokyo, and 41.6 ms versus 74.1 ms from Tokyo back to mainland China.

CTGNet and CN2 should be read as parts of the current China Telecom premium routing path, not as interchangeable words. The useful question is whether the actual path shows the premium China Telecom network in both directions.

For a broader carrier view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Unicom Premium routing and China Mobile CMIN2 routing. To test from Riven Cloud’s Tokyo location, use the Tokyo Looking Glass.