Welcome Guest ( Log In | Register )

Bump Topic Add Reply RSS Feed

Outline · [ Standard ] · Linear+

 Why Is Celcom Equinix SG So Annoyingly Lousy?, High Packet Loses & Latency to M247 SG

views
     
SUSpetpenyubobo
post May 31 2025, 12:36 PM, updated 7 months ago

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
Why is Sialkom's connectivity to Equinix Singapore so annoyingly lousy?

Average latency to M247 SG servers is almost 100ms with high packet losses.

user posted image

user posted image

user posted image

Due to this, Celcom connectivity to many SG servers/hosting providers that peers with Equinix SG IX is getting choked!

user posted image

For comparison, if you look at Maxis's bandwidth to Equinix SG (500Gbps), it has 10X the capacity of Sialkom's bandwidth (50Gbps).

It causes my connections to nearby M247 SG, Akamai servers, Cisco Webex, Apple Cloud, Zhejiang Taobao, GoDaddy, Adobe, IBM Cloud, eBay, Sony Interactive, Facebook, Tiktok and all to be seriously bottleneck?

ISPs and Hosting Providers That Peers with Equinix SG
https://bgpview.io/ix/90

Will the slim shady Mohd Najib Mahmood of CelcomDigi please stand up? laugh.gif
GalaxyV
post May 31 2025, 12:39 PM

Enthusiast
*****
Junior Member
791 posts

Joined: Apr 2018
yes, i dont like celcom

the best is still maxis
tng55
post May 31 2025, 01:45 PM

Regular
******
Senior Member
1,449 posts

Joined: Sep 2021
i also don't like celcom pospaid mobile daam

i still prefer maxis pospaid mobile

almost buffering and whatsapp image load slow to much sometime 4g too

but maxis very fast 4g too
SUSpetpenyubobo
post May 31 2025, 01:54 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(tng55 @ May 31 2025, 01:45 PM)
i also don't like celcom pospaid mobile daam

i still prefer maxis pospaid mobile

almost buffering and whatsapp image load slow to much sometime 4g too

but maxis very fast 4g too
*
Muh Mood is lost even on Saturdays using Sialkom!

CelcomDigi team is always sleeping. So obvious problem and ongoing issue that has been highlighted for many months already they still sitting on it.

Their network team needs constant complaints from their subscribers/customers before taking actions.
faizyunus
post May 31 2025, 05:10 PM

Casual
***
Junior Member
444 posts

Joined: Feb 2014
Looking at your traceroute, it seems the high latency is at m247.ro which is definitely not Equinix.

However in order to be certain, need to run traceroute from the affected site/hosting provider/server to any Celcom IP address. Sometimes the return route can take different path from your outbound traceroute.


From my experience, its a pain to gather this info when ISP request for it. Urghhh
SUSpetpenyubobo
post May 31 2025, 05:21 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(faizyunus @ May 31 2025, 05:10 PM)
Looking at your traceroute, it seems the high latency is at m247.ro which is definitely not Equinix.

However in order to be certain, need to run traceroute from the affected site/hosting provider/server to any Celcom IP address. Sometimes the return route can take different path from your outbound traceroute.
From my experience, its a pain to gather this info when ISP request for it. Urghhh
*
Unlike DataPacket Telecom, M247 has no public based reverse traceroute/MTR facility.

I could obtain Celcom's public test server IPs to do the reverse traceroute/MTR tests.

M247 is now the most popular provider used by Singaporean based VPN servers.

Also I've noticed that despite Celcom having merged with DiGi, both companies still maintain their own respective pool of IP ranges and own gateways with Pelan Biru and Pelan Kuning.

user posted image

user posted image

This post has been edited by petpenyubobo: May 31 2025, 05:23 PM
kwss
post May 31 2025, 08:28 PM

Regular
******
Senior Member
1,208 posts

Joined: Aug 2018
I am using Sialcom and yes it sucks hard at a lot of place. If the area works fine then all is good.

I have AWS instance in SG and route via Equinix as well. Seems to works well with Sialcom in good area.

I tried to do a reverse traceroute and it seems blocked when it reached Sialcom network. Ping don't work too. So even if you can get a machine on M247, don't think you can test much. I hate network that block diagnostic tools. Only shitty network need to prevent people from doing diagnostic.

CODE

traceroute to 2404:160:8176:ff6a:2da2:15c8:a55d:2036
(2404:160:8176:ff6a:2da2:15c8:a55d:2036), 30 hops max, 80 byte packets
1  2400:6500::75 (2400:6500::75)  1.683 ms 2400:6500::11 (2400:6500::11)  1.000 ms 2400:6500::75 (2400:6500::75)  1.644 ms
2  * * *
3  2620:107:4000:cfff::f204:4d87 (2620:107:4000:cfff::f204:4d87)  1.409 ms 2620:107:4000:cfff::f204:4d05
(2620:107:4000:cfff::f204:4d05)  1.770 ms 2620:107:4000:cfff::f204:4d03 (2620:107:4000:cfff::f204:4d03)  1.947 ms
4  2400:6500::3c (2400:6500::3c)  1.861 ms  1.798 ms  1.783 ms
5  10030.sgw.equinix.com (2001:de8:4::1:30:1)  11.867 ms  11.483 ms  11.671 ms
6  * * *
7  * * *


Ping via wireguard tunnel
CODE

PING fcaa::b (fcaa::b) 56 data bytes
64 bytes from fcaa::b: icmp_seq=1 ttl=64 time=44.9 ms64 bytes from fcaa::b: icmp_seq=2 ttl=64 time=63.7 ms64 bytes from fcaa::b: icmp_seq=3 ttl=64 time=82.3 ms64 bytes from fcaa::b: icmp_seq=4 ttl=64 time=150 ms
64 bytes from fcaa::b: icmp_seq=5 ttl=64 time=108 ms
64 bytes from fcaa::b: icmp_seq=6 ttl=64 time=68.9 ms64 bytes from fcaa::b: icmp_seq=7 ttl=64 time=177 ms
64 bytes from fcaa::b: icmp_seq=8 ttl=64 time=126 ms
64 bytes from fcaa::b: icmp_seq=9 ttl=64 time=94.2 ms64 bytes from fcaa::b: icmp_seq=10 ttl=64 time=52.9 ms
--- fcaa::b ping statistics ---
10 packets transmitted, 10 received, 0% packet loss,
time 9013ms
rtt min/avg/max/mdev = 44.901/96.860/177.393/41.270 ms


I run IPv6 only instance on AWS, so no IPv4 address to test.

So... Either Celcom sucks at your place or M247 problem.
M247 only have 2x10Gbps peering in Equinix SG. If all VPN providers use them like you said, I don't think that's enough bandwidth.
SUSpetpenyubobo
post May 31 2025, 08:35 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(kwss @ May 31 2025, 08:28 PM)
I am using Sialcom and yes it sucks hard at a lot of place. If the area works fine then all is good.

I have AWS instance in SG and route via Equinix as well. Seems to works well with Sialcom in good area.

I tried to do a reverse traceroute and it seems blocked when it reached Sialcom network. Ping don't work too. So even if you can get a machine on M247, don't think you can test much. I hate network that block diagnostic tools. Only shitty network need to prevent people from doing diagnostic.

I run IPv6 only instance on AWS, so no IPv4 address to test.

So... Either Celcom sucks at your place or M247 problem.
M247 only have 2x10Gbps peering in Equinix SG. If all VPN providers use them like you said, I don't think that's enough bandwidth.
*
Celcom works best with DataPacket Telecom(AS60068) though probably due to its high Cogent reliance.

Outside that if the internet provider/VPN server is Equinix SG IX peer, you'll not get optimum results.

I also hate Cogent when it comes to European links. They're only good for Transatlantic links between Eastern US across the Atlantic to Europe not from SEA to Europe via ME. That one Telecom Italia's SEABONE routes thrugh Palermo, Italy and Marseilles, France.
kwss
post May 31 2025, 09:38 PM

Regular
******
Senior Member
1,208 posts

Joined: Aug 2018
QUOTE(petpenyubobo @ May 31 2025, 08:35 PM)
Celcom works best with DataPacket Telecom(AS60068) though probably due to its high Cogent reliance.

Outside that if the internet provider/VPN server is Equinix SG IX peer, you'll not get optimum results.

I also hate Cogent when it comes to European links. They're only good for Transatlantic links between Eastern US across the Atlantic to Europe not from SEA to Europe via ME. That one Telecom Italia's SEABONE routes thrugh Palermo, Italy and Marseilles, France.
*
Cogent is a piece of shit and well known to de-peer people without notice. Happened to Level3, NTT, TATA.

Suddenly half the network don't work and you realized the routing table is gone. Thanks but no thanks Cogent.

Anytime I am in a position of power to decide I ban the hell out of them.

Your EU problem is due to their most recent de-peering with TATA. A lot EU traffic needs to go to America.
iXora.ix
post May 31 2025, 11:00 PM

scoot scoot
******
Senior Member
1,682 posts

Joined: Jan 2007
From: Kuala Lumpur
not sure related but im using both celcom fiber and celcom line, connected to zscaler server also affected. But i think it worst during last year/early 2025. Now solve already after multiple ticket to cd and mcmc. seems much better la compare to previous I sign up celcom fiber

had to use vpn to sg to get better ms in zscaler. dah la zscaler vpn, on top vpn baru okay laugh.gif
heLL_bOy
post May 31 2025, 11:53 PM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(kwss @ May 31 2025, 09:38 PM)
Cogent is a piece of shit and well known to de-peer people without notice. Happened to Level3, NTT, TATA.

Suddenly half the network don't work and you realized the routing table is gone. Thanks but no thanks Cogent.

Anytime I am in a position of power to decide I ban the hell out of them.

Your EU problem is due to their most recent de-peering with TATA. A lot EU traffic needs to go to America.
*
Well, Cogent is better then hurricane electric imho
heLL_bOy
post May 31 2025, 11:55 PM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(petpenyubobo @ May 31 2025, 08:35 PM)
Celcom works best with DataPacket Telecom(AS60068) though probably due to its high Cogent reliance.

Outside that if the internet provider/VPN server is Equinix SG IX peer, you'll not get optimum results.

I also hate Cogent when it comes to European links. They're only good for Transatlantic links between Eastern US across the Atlantic to Europe not from SEA to Europe via ME. That one Telecom Italia's SEABONE routes thrugh Palermo, Italy and Marseilles, France.
*
Datapacket is better then M247 in overall on their routing.
SUSpetpenyubobo
post Jun 1 2025, 12:27 AM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(kwss @ May 31 2025, 09:38 PM)
Cogent is a piece of shit and well known to de-peer people without notice. Happened to Level3, NTT, TATA.

Suddenly half the network don't work and you realized the routing table is gone. Thanks but no thanks Cogent.

Anytime I am in a position of power to decide I ban the hell out of them.

Your EU problem is due to their most recent de-peering with TATA. A lot EU traffic needs to go to America.
*
Ah I can finally understand now why some of my European VPN servers are above 300ms+
Even DataPacket Telecom servers located in Scandinavia, London and Ireland.

MTR results show it going all the way around the world across the Pacific Ocean to US then across the Atlantic instead of the Middle East route.

Thanks to Cogent crap routing.

Of all the ISPs, Sialkom is the only big fan of Cogent. The other ISP that also relies heavily on Cogent is TNB Allo.

The rest of the other telcos have moved away from them. TM Technology Services, TIME, Maxis, Umobile and Yes prefers the Hurricane Electric route + Telecom Italia's SEABONE to reach Europe via ME.

QUOTE(heLL_bOy @ May 31 2025, 11:55 PM)
Datapacket is better then M247 in overall on their routing.
*
This is because they use Cogent primarily as one of their top upstream provider.

Some of the DataPacket IP blocks are identified/announce as Cogent Communications when you do speed tests.

This post has been edited by petpenyubobo: Jun 1 2025, 12:29 AM
kwss
post Jun 1 2025, 12:39 AM

Regular
******
Senior Member
1,208 posts

Joined: Aug 2018
QUOTE(heLL_bOy @ May 31 2025, 11:53 PM)
Well, Cogent is better then hurricane electric imho
*
In terms of total number of ASN coverage, yes. Everything else is kind of debatable.
In term of service and quality I can also say TATA is worst. They are borderline to "don't know what they are doing" in this space.

QUOTE(petpenyubobo @ Jun 1 2025, 12:27 AM)
Ah I can finally understand now why some of my European VPN servers are above 300ms+
Even DataPacket Telecom servers located in Scandinavia, London and Ireland.

MTR results show it going all the way around the world across the Pacific Ocean to US then across the Atlantic instead of the Middle East route.

Thanks to Cogent crap routing.

Of all the ISPs, Sialkom is the only big fan of Cogent. The other ISP that also relies heavily on Cogent is TNB Allo.

The rest of the other telcos have moved away from them. TM Technology Services, TIME, Maxis, Umobile and Yes prefers the Hurricane Electric route + Telecom Italia's SEABONE to reach Europe via ME.
This is because they use Cogent primarily as one of their top upstream provider.

Some of the DataPacket IP blocks are identified/announce as Cogent Communications when you do speed tests.
*
Cogent is cheap. Really cheap. For economy telco, they will just use it.
Afterall, economy telco mostly don't provide SLA (or SLA only for local service uptime), so it is risk free + cost effective.
Network mati then mati loh. You are on your own.

This post has been edited by kwss: Jun 1 2025, 12:41 AM
heLL_bOy
post Jun 1 2025, 12:55 AM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(kwss @ Jun 1 2025, 12:39 AM)
In terms of total number of ASN coverage, yes. Everything else is kind of debatable.
In term of service and quality I can also say TATA is worst. They are borderline to "don't know what they are doing" in this space.
*
Afaik currently, TATA during peak hours(8pm onward) their connectivity between APAC and US region may experiencing high ping and loss packet. Not sure are they oversell their bandwidth.

Above high ping and loss packet also happen in between their peers within NTT , PCCW and Telia.
heLL_bOy
post Jun 1 2025, 12:57 AM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(petpenyubobo @ Jun 1 2025, 12:27 AM)
Some of the DataPacket IP blocks are identified/announce as Cogent Communications when you do speed tests.
*
Cogent also doing IP leasing dont forget. Maybe the ip block that you mentioned are renting from Cogent.
SUSpetpenyubobo
post Jun 6 2025, 06:39 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
Now the latest routing issue with Sialkom is its Japan route.

Average latency is above 300ms to reach DataPacket servers in Tokyo when all other local telcos only below 90ms.

They rely on NTT and China Mobile (return path) to reach DataPacket servers in Tokyo but for some reason it the latency is tripled before returning to DataPacket Tokyo server.

If you're on Celcom network right now(not DiGi AS4818), do a simple ping to DataPacket Tokyo Test IP 89.187.160.1 you'll know why they're lousy.
SUSpetpenyubobo
post Jun 6 2025, 06:48 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(heLL_bOy @ Jun 1 2025, 12:57 AM)
Cogent also doing IP leasing dont forget. Maybe the ip block that you mentioned are renting from Cogent.
*
Please learn from the trend of now the leading telcos in this region such as Singtel and AIS Thailand.

They separate their transit services depts from their consumer ISPs and concentrate on routing/transit services alone.

AIS has AS45430 SBN-IIG/AWN-IIG exchange while Singtel has AS3758 SingNet & AS7473 Singapore Telecommunications Ltd

DiGi once had its own transit IX company when it was under Telenor last time which managed the gateways for both DTAC and DiGi las time.

TM also has TM Technology Services now.
heLL_bOy
post Jun 7 2025, 11:40 AM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(petpenyubobo @ Jun 6 2025, 06:48 PM)
Please learn from the trend of now the leading telcos in this region such as Singtel and AIS Thailand.

They separate their transit services depts from their consumer ISPs and concentrate on routing/transit services alone.

AIS has AS45430 SBN-IIG/AWN-IIG exchange while Singtel has AS3758 SingNet & AS7473 Singapore Telecommunications Ltd

DiGi once had its own transit IX company when it was under Telenor last time which managed the gateways for both DTAC and DiGi las time.

TM also has TM Technology Services now.
*
what wrong with IP leasing? Is different from Ip transit services and no need to have different ASN for ip leasing services
SUSpetpenyubobo
post Jun 7 2025, 01:56 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(heLL_bOy @ Jun 7 2025, 11:40 AM)
what wrong with IP leasing?  Is different from Ip transit services and no need to have different ASN for ip leasing services
*
This recent Japan routing issue with Sialkom is an example of lousy Cogent support is.

It refuses and denies Sialkom from using its route to Japan forcing NTT to do low priority routing to Japan instead.

The result is 3X the usual ping to DataPacket TKY,Japan when using Sialkom. Reverse traceroute from DataPacket Tokyo back to Celcom also shows that despite Cogent being among their top upstream provider, it is forced to use China Mobile route instead to return to Malaysia.

You don't have this issues with other telcos such as YES which uses Hurricane Electric route and TIME which has very good Japanese peering which has the LOWEST latency rates to Japan among all Malaysian telcos.

DataPacket Tokyo to YTLComms

CODE
HOST: 10g-tokyo-kvm-1-89-187-160- Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS60068  89.187.160.61        0.0%    10    0.1   0.1   0.1   0.1   0.0
 2. AS???    169.150.194.190      0.0%    10    0.2   0.2   0.1   0.2   0.0
 3. AS???    101.203.88.74       80.0%    10    0.7   0.7   0.7   0.7   0.0
 4. AS6939   184.104.194.126     40.0%    10   84.9  84.9  84.7  85.2   0.0
 5. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0


DataPacket Tokyo to TDC

CODE
HOST: 10g-tokyo-kvm-1-89-187-160- Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS60068  89.187.160.60        0.0%    10    0.1   0.1   0.1   0.2   0.0
 2. AS???    169.150.194.188      0.0%    10    0.1   0.1   0.1   0.2   0.0
 3. AS2914   61.200.82.185        0.0%    10    0.2   0.2   0.2   0.3   0.0
 4. AS2914   129.250.5.90        70.0%    10    0.7   2.1   0.7   4.0   1.6
 5. AS2914   129.250.2.242       30.0%    10   67.2  67.3  67.2  67.4   0.0
 6. AS2914   129.250.2.169       30.0%    10   71.7  71.4  71.0  71.8   0.0
 7. AS2914   129.250.3.230        0.0%    10   72.7  73.3  72.5  74.1   0.5
 8. AS2914   168.143.105.231      0.0%    10   79.4  79.4  79.4  79.8   0.0
 9. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
10. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
11. AS9930   223.28.43.78         0.0%    10   73.4  73.5  73.3  73.6   0.0
12. AS9930   223.28.57.66         0.0%    10   72.1  72.2  72.1  72.2   0.0



This post has been edited by petpenyubobo: Jun 7 2025, 01:58 PM
heLL_bOy
post Jun 7 2025, 02:31 PM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(petpenyubobo @ Jun 7 2025, 01:56 PM)
This recent Japan routing issue with Sialkom is an example of lousy Cogent support is.

It refuses and denies Sialkom from using its route to Japan forcing NTT to do low priority routing to Japan instead.

The result is 3X the usual ping to DataPacket TKY,Japan when using Sialkom. Reverse traceroute from DataPacket Tokyo back to Celcom also shows that despite Cogent being among their top upstream provider, it is forced to use China Mobile route instead to return to Malaysia.

You don't have this issues with other telcos such as YES which uses Hurricane Electric route and TIME which has very good Japanese peering which has the LOWEST latency rates to Japan among all Malaysian telcos.

DataPacket Tokyo to YTLComms

CODE
HOST: 10g-tokyo-kvm-1-89-187-160- Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS60068  89.187.160.61        0.0%    10    0.1   0.1   0.1   0.1   0.0
 2. AS???    169.150.194.190      0.0%    10    0.2   0.2   0.1   0.2   0.0
 3. AS???    101.203.88.74       80.0%    10    0.7   0.7   0.7   0.7   0.0
 4. AS6939   184.104.194.126     40.0%    10   84.9  84.9  84.7  85.2   0.0
 5. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0


DataPacket Tokyo to TDC

CODE
HOST: 10g-tokyo-kvm-1-89-187-160- Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS60068  89.187.160.60        0.0%    10    0.1   0.1   0.1   0.2   0.0
 2. AS???    169.150.194.188      0.0%    10    0.1   0.1   0.1   0.2   0.0
 3. AS2914   61.200.82.185        0.0%    10    0.2   0.2   0.2   0.3   0.0
 4. AS2914   129.250.5.90        70.0%    10    0.7   2.1   0.7   4.0   1.6
 5. AS2914   129.250.2.242       30.0%    10   67.2  67.3  67.2  67.4   0.0
 6. AS2914   129.250.2.169       30.0%    10   71.7  71.4  71.0  71.8   0.0
 7. AS2914   129.250.3.230        0.0%    10   72.7  73.3  72.5  74.1   0.5
 8. AS2914   168.143.105.231      0.0%    10   79.4  79.4  79.4  79.8   0.0
 9. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
10. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
11. AS9930   223.28.43.78         0.0%    10   73.4  73.5  73.3  73.6   0.0
12. AS9930   223.28.57.66         0.0%    10   72.1  72.2  72.1  72.2   0.0

*
i did a MTR on china mobile MY and SG and cogent SG with datapacket tokyo ip (both way using same IP transit routing)

the issue is from china mobile itself. nothing wrong with cogent so far.

This post has been edited by heLL_bOy: Jun 7 2025, 02:32 PM
SUSpetpenyubobo
post Jun 7 2025, 02:48 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(heLL_bOy @ Jun 7 2025, 02:31 PM)
i did a MTR on china mobile MY and SG and cogent SG with datapacket tokyo ip (both way using same IP transit routing)

the issue is from china mobile itself. nothing wrong with cogent so far.
*
Have you did a MTR to DataPacket Tokyo from Celcom side instead?

user posted image
heLL_bOy
post Jun 7 2025, 05:06 PM

Regular
******
Senior Member
1,350 posts

Joined: Nov 2004
From: HEAVEN & HELL
QUOTE(petpenyubobo @ Jun 7 2025, 02:48 PM)
Have you did a MTR to DataPacket Tokyo from Celcom side instead?

user posted image
*
i dont have celcom to test, the only i could test is using celcom speedtest ip.

tested on NTT and Cogent to Datapacket JP no issue the ping between <80ms with no packet loss.

the only issue is china mobile upstream right now, tested their LA,HK,SG and MY location all direction is having issue to Datapacket JP with both way routes.

another found out is China mobile2 transit SG having no issue also to datapacket JP. I guess the normal china mobile transit get DDos or external problem.

another test was using china mobile using peers transit over Level3 which is no issue. (China mobile MY/SG > Level 3 > JP destination)
ansonlos
post Jun 7 2025, 05:53 PM

New Member
*
Newbie
12 posts

Joined: Jul 2009
@petpenyubobo Think it has to do with the IP range you're on. I'm also using Celcom Fibre for my house, though it's a cgnat, but my public IP is in the range of 183.171.249.x. My ping to Tokyo, Japan is in the range of 80 - 90ms.

Here's MTR from my house to Datapacket Telecom test IP:

CODE
HOST: private                               Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 172.17.34.1                           0.0%    50    2.8   2.7   1.7   3.8   0.4
 2.|-- 183.171.206.46                        0.0%    50    9.6  10.9   7.6  45.4   7.8
 3.|-- 183.171.206.41                        0.0%    50    5.0   4.7   3.2   6.6   0.5
 4.|-- 10.151.27.11                          0.0%    50    3.9   4.1   2.5   6.0   0.7
 5.|-- 183.171.205.113                       2.0%    50    5.2   4.5   3.3  16.1   1.7
 6.|-- 203.82.83.42                          0.0%    50   27.2  29.0  17.1  47.4   5.7
 7.|-- 203.82.83.28                          0.0%    50    5.8   5.9   4.7   7.2   0.4
 8.|-- ae-4.r01.kslrml02.my.bb.gin.ntt.net   0.0%    50    6.6   6.2   5.3   7.3   0.4
 9.|-- ae-2.r23.kslrml02.my.bb.gin.ntt.net   0.0%    50    5.8   7.9   5.3  18.5   3.0
10.|-- ae-8.r25.sngpsi07.sg.bb.gin.ntt.net  14.0%    50   11.7  11.8  10.7  12.8   0.3
11.|-- ae-13.r33.tokyjp05.jp.bb.gin.ntt.net 92.0%    50   78.8  79.1  78.5  79.5   0.5
12.|-- ae-7.a00.tokyjp09.jp.bb.gin.ntt.net   0.0%    50   78.6  78.7  77.3  83.4   1.2
13.|-- 61.120.145.2                          0.0%    50   88.6  88.5  87.4  89.3   0.4
14.|-- vl205.tyo-eq8-dist-1.cdn77.com        0.0%    50   93.6  93.4  92.3  95.0   0.5
15.|-- 552338339.tyo.cdn77.com               0.0%    50   88.9  88.5  87.5  89.5   0.3


Here's MTR from my Tokyo VPS (Softbank network) to your test Celcom IP:

CODE
HOST: tokyovps                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 36.50.84.1                0.0%    50    1.5   0.7   0.5   1.5   0.2
 2.|-- 91.200.240.124            0.0%    50    5.3  22.4   5.3 124.5  22.2
 3.|-- 91.200.240.118            0.0%    50   91.9   3.8   0.9  91.9  13.4
 4.|-- 91.200.240.64             0.0%    50    0.9   1.4   0.8  20.0   2.7
 5.|-- 91.200.240.63             0.0%    50   87.5   5.6   1.4  87.5  13.5
 6.|-- 91.200.240.102            0.0%    50    1.5   3.9   1.3 105.8  14.8
 7.|-- 203.190.231.8             0.0%    50    1.0   1.0   0.7   4.3   0.5
 8.|-- 58453.tyo.equinix.com     0.0%    50  228.5 175.4  57.1 290.3  51.8
 9.|-- 223.118.3.5               0.0%    50  243.0 174.9  51.3 288.5  53.4
10.|-- 223.118.6.86              0.0%    50  262.4 175.4  49.4 281.7  54.5
11.|-- 223.120.3.237             0.0%    50  350.3 254.9 144.5 375.9  57.6
12.|-- 223.120.22.101            0.0%    50  367.1 256.2 148.9 376.7  56.7
13.|-- 223.119.6.242             0.0%    50  348.4 248.6 137.0 384.2  57.1
14.|-- 203.82.83.31             12.0%    50  3493. 3596. 3276. 3899. 149.3
15.|-- 203.82.83.78              0.0%    50  320.6 248.2 152.0 404.5  54.2
16.|-- speedokpg1.celcom.net.my  0.0%    50  319.1 247.9 147.8 390.1  52.2


Here's another MTR from Tokyo to another Celcom IP in the 183.171.xx.xx range:

CODE
HOST: tokyovps                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 36.50.84.1                                  0.0%    50    1.0   0.7   0.6   1.3   0.1
 2.|-- 91.200.240.124                              0.0%    50   14.0  26.3   2.1 150.8  32.4
 3.|-- 91.200.240.116                              0.0%    50    1.2   2.6   1.0  38.5   6.1
 4.|-- 91.200.240.64                               0.0%    50    0.9   1.0   0.8   1.2   0.1
 5.|-- 91.200.240.65                               0.0%    50    1.5   5.4   1.3 110.9  17.4
 6.|-- 91.200.240.100                              0.0%    50    1.3   1.4   1.2   2.3   0.2
 7.|-- 31.217.251.155                              0.0%    50    0.8   1.1   0.6  17.1   2.3
 8.|-- e8.ty-eqxty2-cr7.globalsecurelayer.com      0.0%    50    0.8   0.7   0.6   0.8   0.0
 9.|-- po401.ty-eqxty2-bb10.globalsecurelayer.com  0.0%    50    1.0   0.9   0.7   1.6   0.1
10.|-- 103.107.199.81                              0.0%    50   68.0  67.5  67.4  68.7   0.2
11.|-- 4818-sg1-ix.equinix.com                    32.0%    50   67.7  67.6  67.5  67.7   0.1
12.|-- ???                                        100.0    50    0.0   0.0   0.0   0.0   0.0
13.|-- 115.164.100.2                               0.0%    50   75.5  76.0  75.0  90.6   2.8
14.|-- 203.82.78.8                                 0.0%    50  103.1 102.9 102.6 104.5   0.4
15.|-- 203.82.78.203                               0.0%    50   98.5  98.4  98.3  98.6   0.0
16.|-- ???                                        100.0    50    0.0   0.0   0.0   0.0   0.0
17.|-- ???                                        100.0    50    0.0   0.0   0.0   0.0   0.0
18.|-- ???                                        100.0    50    0.0   0.0   0.0   0.0   0.0
19.|-- spf.ctci-kimanis.com.my                     0.0%    50  101.9 102.0 101.7 103.8   0.4


Gather what you will from the above two MTRs for 203 vs 183 IP ranges.

For the past several months the latency to Japan was no doubt horrendous. But things have now been 'fixed' (for how long is anyone's guess) in my case; in fact, most international routing (to US, UK, Japan, etc) has gone back to the 'norm' since recent weeks, and useable regardless of day or night. Again, this is for my IP range. Heehee... all this kinda reminds me of my previous experience with TM Unifi; international routing mostly crap in the evening, hence, I changed to Celcom Fibre hoping for better experience especially in the evening/night.

I know this is not going to help resolve your situation, but just want to share my experience as another fellow Celcom Fibre subscriber.

On another note, if anyone on Celcom Fibre manages to get IPv6 (routed prefix delegation) working, please share. Thanks!

This post has been edited by ansonlos: Jun 7 2025, 06:03 PM
SUSpetpenyubobo
post Jun 7 2025, 07:56 PM

Regular
******
Senior Member
1,030 posts

Joined: Jan 2022
QUOTE(ansonlos @ Jun 7 2025, 05:53 PM)
@petpenyubobo Think it has to do with the IP range you're on. I'm also using Celcom Fibre for my house, though it's a cgnat, but my public IP is in the range of 183.171.249.x. My ping to Tokyo, Japan is in the range of 80 - 90ms.

For the past several months the latency to Japan was no doubt horrendous. But things have now been 'fixed' (for how long is anyone's guess) in my case; in fact, most international routing (to US, UK, Japan, etc) has gone back to the 'norm' since recent weeks, and useable regardless of day or night. Again, this is for my IP range. Heehee... all this kinda reminds me of my previous experience with TM Unifi; international routing mostly crap in the evening, hence, I changed to Celcom Fibre hoping for better experience especially in the evening/night.

I know this is not going to help resolve your situation, but just want to share my experience as another fellow Celcom Fibre subscriber.

On another note, if anyone on Celcom Fibre manages to get IPv6 (routed prefix delegation) working, please share. Thanks!
*
I have since recycled power my 5G modem few times already and getting ip ranges between 183.171.50.x - 183.171.100.x IP CGNAT as well.

Celcom Europe links are via Cogent AS174.

The issues is affecting both direction for Celcom. You noticed that your Tokyo VPS is getting 300ms+ on return path after it exits DataPacket Tokyo via China Mobile route?

Celcom uses these 3 particular routes to reach or return path from Japan either NTT, Cogent or China Mobile (preferred path for Data Packet Tokyo back to MY)

My previous MTR result shows the high latency spike is on NTT's as soon as it hits Japan side.

user posted image

My most pleasant experience to be honest was on Maxis Fibre days. This kind of issues were almost non existent.
« Next Oldest · Networks and Broadband · Next Newest »
 

Add ReplyOptions
 

Change to:
| Lo-Fi Version
 0.0204sec    0.93    5 queries    GZIP Disabled
Time is now: 19th December 2025 - 01:02 AM
All Rights Reserved © 2002- 2025 Vijandren Ramadass (~unite against racism~)
Removal Request
Powered by Invision Power Board © 2025  IPS, Inc.