Welcome Guest ( Log In | Register )

Outline · [ Standard ] · Linear+

 Celcom Messed Up Its Japan DataPacket Route?, All Other Local Telcos Just Fine

views
     
SUSpetpenyubobo
post Jun 6 2025, 06:06 PM, updated 5 months ago

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

Joined: Jan 2022

It's been months now since early this year Sialkom's Routing to DataPacket Tokyo, JPN has been over 300ms with no resolved till date.

They even have celcomdigi-sgp.cdn77.com private peering with DataPacket Telecom in Singapore but why?

MohdNajib Mahmood, bossku please tell us why your routing is really the most sial among all the other telcos?

user posted image

DataPacket Tokyo, Japan to Celcom

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.2   0.0
 2. AS???    169.150.194.142      0.0%    10    0.1   0.2   0.1   0.2   0.0
 3. AS???    203.190.230.108      0.0%    10  243.2 264.1 243.2 271.3   8.1
 4. AS58453  223.120.2.249       10.0%    10  283.8 295.3 283.8 304.5   6.4
 5. AS58453  223.120.2.33        10.0%    10  250.9 257.9 245.1 275.0   9.6
 6. AS58453  223.120.3.237       10.0%    10  257.7 257.7 238.1 279.7  12.5
 7. AS58453  223.120.22.101       0.0%    10  270.4 263.4 240.5 282.1  11.7
 8. AS58453  223.119.6.242        0.0%    10  278.6 270.2 250.8 288.2  12.0
 9. AS10030  203.82.83.29         0.0%    10  298.7 287.4 266.0 315.6  16.9
10. AS10030  203.82.83.76        10.0%    10  269.4 267.3 247.7 285.6  15.6
11. AS10030  203.82.87.4          0.0%    10  261.9 268.6 243.4 284.8  15.0


From Celcom to DataPacket Tokyo, Japan also same lame result

DataPacket Tokyo Test IP from Celcom:
QUOTE
89.187.160.1


user posted image

Can you at least learn from your sister company or colleagues from DiGi how to properly manage your transit routing paths?

How come DiGi's end don't have this issue?

user posted image

DataPacket Tokyo to DiGi

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.2   0.1   0.1   0.2   0.0
 3. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
 4. AS174    154.54.89.202        0.0%    10   53.6  53.7  53.5  54.2   0.0
 5. AS174    154.54.87.225        0.0%    10   76.1  75.9  75.8  76.1   0.0
 6. AS174    154.18.16.183        0.0%    10   75.5  75.5  75.5  75.6   0.0
 7. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
 8. AS4818   115.164.0.161        0.0%    10   82.9  82.9  82.8  82.9   0.0
 9. AS4818   115.164.0.162        0.0%    10   82.6  82.7  82.6  82.7   0.0


This post has been edited by petpenyubobo: Jun 6 2025, 06:09 PM
SUSpetpenyubobo
post Jun 6 2025, 06:07 PM

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

Joined: Jan 2022

DataPacket Tokyo to TM Technology Services

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.2   0.1   0.1   0.2   0.0
 2. AS???    169.150.194.142      0.0%    10    0.1   0.1   0.1   0.2   0.0
 3. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
 4. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
 5. AS6939   65.49.109.190       70.0%    10   73.5  73.5  73.4  73.5   0.0
 6. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0


DataPacket Tokyo to Maxis

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.2   0.0
 2. AS???    169.150.194.142      0.0%    10    0.1   0.1   0.1   0.2   0.0
 3. AS2914   61.120.145.1         0.0%    10    0.2   0.2   0.2   0.4   0.0
 4. AS2914   129.250.5.48        80.0%    10    4.4   2.8   1.3   4.4   2.0
 5. AS2914   129.250.2.242        0.0%    10   67.9  67.7  67.6  67.9   0.0
 6. AS2914   129.250.2.169        0.0%    10   73.0  73.8  72.9  75.8   0.9
 7. AS2914   129.250.6.25         0.0%    10   73.1  73.1  73.0  73.4   0.0
 8. AS2914   203.78.193.182       0.0%    10   73.1  73.1  73.0  73.3   0.0
 9. AS9534   202.75.151.82        0.0%    10   79.5  79.5  79.5  79.6   0.0


DataPacket Tokyo to DiGi

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.2   0.1   0.1   0.2   0.0
 3. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
 4. AS174    154.54.89.202        0.0%    10   53.6  53.7  53.5  54.2   0.0
 5. AS174    154.54.87.225        0.0%    10   76.1  75.9  75.8  76.1   0.0
 6. AS174    154.18.16.183        0.0%    10   75.5  75.5  75.5  75.6   0.0
 7. AS???    ???                 100.0    10    0.0   0.0   0.0   0.0   0.0
 8. AS4818   115.164.0.161        0.0%    10   82.9  82.9  82.8  82.9   0.0
 9. AS4818   115.164.0.162        0.0%    10   82.6  82.7  82.6  82.7   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


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


All the other Malaysian ISPs are getting under 90ms to DataPacket, Tokyo but with Sialkom the latency is over 300ms on average?

So special one kah Sialkom? It's been months already like this someone is really sleeping on their jobs but even funnier their merged company now runs with 2 different gateways that are managed by 2 separate teams.

This post has been edited by petpenyubobo: Jun 6 2025, 06:12 PM
heLL_bOy
post Jul 7 2025, 09:48 PM

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

Joined: Nov 2004
From: HEAVEN & HELL


in your case, why not you sent a feedback report to the VPN company you using and asking them to contact upstream to do routing adjustment for egress and " not to use china mobile route " back to Celcom ASN.

This post has been edited by heLL_bOy: Jul 7 2025, 09:48 PM
SUSpetpenyubobo
post Jul 7 2025, 09:52 PM

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

Joined: Jan 2022

QUOTE(heLL_bOy @ Jul 7 2025, 09:48 PM)
in your case, why not you sent a feedback report to the VPN company you using and asking them to contact upstream to do routing adjustment for egress and " not to use china mobile route " back to Celcom ASN.
*
It's been improving the past week.

Routes to Japan and Singapore is now normalizing.

Japan DataPacket routes latency is now between 115-130ms mostly for 5G connection. But during peak hours they tend to spike above 200ms.
iXora.ix
post Jul 8 2025, 10:22 PM

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

Joined: Jan 2007
From: Kuala Lumpur



you need to report 1st to celcom and also open ticket to skmm as well. they will contact you. this also same as me whereby celcom fiber connection to nearest zscaler vpn high ping
heLL_bOy
post Jul 9 2025, 12:29 AM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(iXora.ix @ Jul 8 2025, 10:22 PM)
you need to report 1st to celcom and also open ticket to skmm as well. they will contact you. this also same as me whereby celcom fiber connection to nearest zscaler vpn high ping
*
My suggestion is just direct to zscaler and asking them to change route to another upstream is faster then file a report to ask ISP do change it.
Normally route congestion mostly happen is from Source(Zscaler) to destination (Celcom).
iXora.ix
post Jul 9 2025, 10:47 PM

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

Joined: Jan 2007
From: Kuala Lumpur



QUOTE(heLL_bOy @ Jul 9 2025, 12:29 AM)
My suggestion is just direct to zscaler and asking them to change route to another upstream is faster then file a report to ask ISP do change it.
Normally route congestion mostly happen is from Source(Zscaler) to destination (Celcom).
*
ermm, I wanted to do this at first. but this is work vpn, and i need to raise to IT> IT raise to network team> raise to zscaler and so on. sweat.gif
luckily it had been resolve tongue.gif sweat.gif
heLL_bOy
post Jul 10 2025, 02:20 PM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(iXora.ix @ Jul 9 2025, 10:47 PM)
ermm, I wanted to do this at first. but this is work vpn, and i need to raise to IT> IT raise to network team> raise to zscaler and so on. sweat.gif
luckily it had been resolve  tongue.gif sweat.gif
*
yeah understand that, but that was the fastest way to solved the issue in my opinion.

rather then waiting these ISP to change it was really wasting time and effort to explain to them which some might not understand what we want.

This post has been edited by heLL_bOy: Jul 10 2025, 02:27 PM
SUSpetpenyubobo
post Jul 10 2025, 09:01 PM

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

Joined: Jan 2022

It seems resolved but CelcomDiGi's IX peering in SG seems to get congested very easily during peak hours.

The problem happens when it needs to route via Singapore or uses Equinix IX to route to its peers in not just SG but to other places such as Japan, US and other continents.

Those who are on DiGi's AS4818 you'll have better access because of its 400Gbps connection to SG's Equinix.
Usually if you were on DiGi Postpaid/Prepaid or Fibre previously, your IP block will be routed through this gateway.

But if you're on AS10030 Celcom's gateway then touch luck. This are those who were previously from Celcom and all its MVNOs such as TuneTalk, XOX and BeONE..

Go to this website and check what is your ISP ASN under organization ASxxxx..

https://www.iplocation.net/myip

https://ipinfo.io/what-is-my-ip

This post has been edited by petpenyubobo: Jul 10 2025, 09:02 PM
heLL_bOy
post Jul 11 2025, 12:30 AM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(petpenyubobo @ Jul 10 2025, 09:01 PM)
It seems resolved but CelcomDiGi's IX peering in SG seems to get congested very easily during peak hours.

The problem happens when it needs to route via Singapore or uses Equinix IX to route to its peers in not just SG but to other places such as Japan, US and other continents.

Those who are on DiGi's AS4818 you'll have better access because of its 400Gbps connection to SG's Equinix.
Usually if you were on DiGi Postpaid/Prepaid or Fibre previously, your IP block will be routed through this gateway.

But if you're on AS10030 Celcom's gateway then touch luck. This are those who were previously from Celcom and all its MVNOs such as TuneTalk, XOX and BeONE..

Go to this website and check what is your ISP ASN under organization ASxxxx..

https://www.iplocation.net/myip

https://ipinfo.io/what-is-my-ip
*
i did a test on digi speedtest ip, its seem Digi ASN have better network routing at the moment compare to celcom ASN
blacktubi
post Jul 11 2025, 09:27 AM

-
Group Icon
Elite
8,408 posts

Joined: Jul 2008

QUOTE(heLL_bOy @ Jul 11 2025, 12:30 AM)
i did a test on digi speedtest ip, its seem Digi ASN have better network routing at the moment compare to celcom ASN
*
DiGi network team is quite competent actually, partly due to great training and leadership from Telenor back then

Wouldn't say the same about Celcom Axiata
heLL_bOy
post Jul 11 2025, 12:46 PM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(blacktubi @ Jul 11 2025, 09:27 AM)
DiGi network team is quite competent actually, partly due to great training and leadership from Telenor back then

Wouldn't say the same about Celcom Axiata
*
i just wonder why dont they merge the network and expand their network in celcom side.
blacktubi
post Jul 11 2025, 01:43 PM

-
Group Icon
Elite
8,408 posts

Joined: Jul 2008

QUOTE(heLL_bOy @ Jul 11 2025, 12:46 PM)
i just wonder why dont they merge the network and expand their network in celcom side.
*
It will happen eventually

Telco is complex, a lot of interconnect / transit agreement

And, headcount or rather VSS issue also
SUSpetpenyubobo
post Jul 11 2025, 02:01 PM

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

Joined: Jan 2022

QUOTE(heLL_bOy @ Jul 11 2025, 12:46 PM)
i just wonder why dont they merge the network and expand their network in celcom side.
*
If they merged both depts, the incompetent heads that will get chopped.

Office politics will play to try dragging the merger for as long as they can.
iXora.ix
post Jul 12 2025, 08:28 PM

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

Joined: Jan 2007
From: Kuala Lumpur



actually for twitter (X) during night time also suffer slow internet for both fiber and cellular. not affected on digi cellular line btw
heLL_bOy
post Jul 13 2025, 01:09 AM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(iXora.ix @ Jul 12 2025, 08:28 PM)
actually for twitter (X) during night time also suffer slow internet for both fiber and cellular. not affected on digi cellular line btw
*
last time unifi also having same issue, its seem now Celcom also in the list sweat.gif
SUSpetpenyubobo
post Jul 16 2025, 12:46 PM

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

Joined: Jan 2022

QUOTE(heLL_bOy @ Jul 13 2025, 01:09 AM)
last time unifi also having same issue, its seem now Celcom also in the list sweat.gif
*
The key to them are the administrators strategic planning, compare the performing ones from Maxis, DiGi and even Yes vs Celcom and TM teams.

The earlier ones they had figured out that the secret key to congestion avoidance is to establish big pipes to Equinix SG/SGIX where most other regional ISPs are based there.

If you take a look at Axiata Celcom and TM, by subscriber subscriber pool size they out to have very big pipes to these key exchanges but they are doing the opposite because of lousy planning by their sleeping administrators.
heLL_bOy
post Jul 16 2025, 05:14 PM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(petpenyubobo @ Jul 16 2025, 12:46 PM)
The key to them are the administrators strategic planning, compare the performing ones from Maxis, DiGi and even Yes vs Celcom and TM teams.

The earlier ones they had figured out that the secret key to congestion avoidance is to establish big pipes to Equinix SG/SGIX where most other regional ISPs are based there.

If you take a look at Axiata Celcom and TM, by subscriber subscriber pool size they out to have very big pipes to these key exchanges but they are doing the opposite because of lousy planning by their sleeping administrators.
*
even have big pipes if they doesnt know how to manage the traffic is useless also. I can said some of ISP always throw 1 side traffic into basket making all user into congestion mode.

for example,
using single upstream or IX for ingress > 80% of the ISP route is using the same upstream or IX.


that why they should have diversity on their upstream and balancing on each upstream or IX routing to avoid congestion.
SUSpetpenyubobo
post Jul 16 2025, 05:18 PM

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

Joined: Jan 2022

QUOTE(heLL_bOy @ Jul 16 2025, 05:14 PM)
even have big pipes if they doesnt know how to manage the traffic is useless also. I can said some of ISP always throw 1 side traffic into basket making all user into congestion mode.

for example,
using single upstream or IX for ingress  > 80% of the ISP route is using the same upstream or IX.
that why they should have diversity on their upstream and balancing on each upstream or IX routing to avoid congestion.
*
Diversity and participation itself is already happening at Equinix SG/SGIX. The missing link is establishing big pipes before you can consider peering with regional players in Asia and the rest of the world.

Without the connection you can't even start off well with good peering/upstream providers.


heLL_bOy
post Jul 16 2025, 05:27 PM

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

Joined: Nov 2004
From: HEAVEN & HELL


QUOTE(petpenyubobo @ Jul 16 2025, 05:18 PM)
Diversity and participation itself is already happening at Equinix SG/SGIX. The missing link is establishing big pipes before you can consider peering with regional players in Asia and the rest of the world.

Without the connection you can't even start off well with good peering/upstream providers.
*
no matter how big is the pipe ISP have in Equinix or SGIX it doesnt really resolved the congestion in single party, if another party having small pipe for an example like M247 (they dont just serve 1 ISP or 1 users only in their traffic pipe).

the best way divert into different upstream or IX or the best choice is PNI with each others.

2 Pages  1 2 >Top
 

Change to:
| Lo-Fi Version
0.0171sec    0.48    5 queries    GZIP Disabled
Time is now: 6th December 2025 - 05:28 PM