Anime4000, I continue to look into your problem.
Knowing they peer at Equinix SG, I use Equinix Looking Glass:
https://lg.equinixmetal.com/As you can see it go straight to AS133210 EN Technologies Pte Ltd > AS135134 Soon Keat Neo
CODE
BGP routing table entry for 2403:cfc0:1100::/48
Paths: (6 available, best #6, table default)
Not advertised to any peer
8966 132337 133210 135134
2604:1380:4590:ffff::7 from 2604:1380:4590:ffff::7 (86.109.14.7)
Origin IGP, metric 100, localpref 200, valid, internal
Community: 8966:41 8966:8888
Large Community: 54825:5007:6000 54825:5007:6002
AddPath ID: RX 6, TX-All 0 TX-Best-Per-AS 0
Last update: Sat Jul 27 22:18:38 2024
132337 133210 135134
2604:1380:4590:ffff::7 from 2604:1380:4590:ffff::7 (86.109.14.7)
Origin IGP, metric 100, localpref 200, valid, internal
Large Community: 54825:5007:6000 54825:5007:6002
AddPath ID: RX 5, TX-All 0 TX-Best-Per-AS 0
Last update: Sat Jul 27 22:18:38 2024
132337 133210 135134
2604:1380:4590:ffff::7 from 2604:1380:4590:ffff::7 (86.109.14.7)
Origin IGP, metric 100, localpref 200, valid, internal
Large Community: 54825:5007:6000 54825:5007:6002
AddPath ID: RX 3, TX-All 0 TX-Best-Per-AS 0
Last update: Sat Jul 27 22:18:38 2024
4637 8966 132337 133210 135134
2604:1380:4590:ffff::7 from 2604:1380:4590:ffff::7 (86.109.14.7)
Origin IGP, metric 100, localpref 150, valid, internal
Community: 4637:32023 4637:32304 4637:32501 4637:60952
Large Community: 54825:5007:4000 54825:5007:4009
AddPath ID: RX 4, TX-All 0 TX-Best-Per-AS 0
Last update: Wed Jul 24 02:03:11 2024
133210 135134
2604:1380:4590:ffff::7 from 2604:1380:4590:ffff::7 (86.109.14.8)
Origin IGP, metric 100, localpref 200, valid, internal
Community: 24115:65023
Large Community: 24115:1000:2 24115:1001:1 24115:1002:1 24115:1003:1 24115:1004:133210 54825:5007:6000 54825:5007:6002
Originator: 86.109.14.8, Cluster list: 86.109.14.7
AddPath ID: RX 1, TX-All 0 TX-Best-Per-AS 0
Last update: Sat Jul 27 22:19:22 2024
133210 135134
2604:1380:4590:ffff::7 from 2604:1380:4590:ffff::7 (86.109.14.7)
Origin IGP, metric 100, localpref 200, valid, internal, best (Router ID)
Community: 24115:65023
Large Community: 24115:1000:2 24115:1001:1 24115:1002:2 24115:1003:1 24115:1004:133210 54825:5007:6000 54825:5007:6002
AddPath ID: RX 2, TX-All 0 TX-Best-Per-AS 0
Last update: Sat Jul 27 22:18:38 2024
A traceroute from the Looking Glass confirms it:
CODE
traceroute to 2403:cfc0:1100:ff00::2 (2403:cfc0:1100:ff00::2), 15 hops max, 80 byte packets
1 fe80:31::1%bond0 (fe80:31::1%bond0) [*] 0.165 ms
2 fc00:da:0:d::2b (fc00:da:0:d::2b) [*] 0.157 ms
3 fc00:da:0:d::f (fc00:da:0:d::f) [*] 0.543 ms
4 133210-sg1-ix.equinix.com (2001:de8:4::13:3210:1) [*] 1.057 ms <--- egress interface AS133210 EN Technologies Pte Ltd
5 2403:cfc0:1100:ff00::2 (2403:cfc0:1100:ff00::2) [AS135134] 1.047 ms
Now that we have confirmed nothing is wrong with Etisalat (they are never meant to carry the traffic) and Equinix, plus the fact that it works on Celcom, it must be TM.
EDIT:
I have narrowed down the problem to the peering between AS4788 TM and AS132337 Axclusive. All IPv6 traffic meant for AS132337 Axclusive will end up getting dumped into Etisalat. IPv4 works fine.
I am also not sure why TM never send traffic directly to AS133210 EN Technologies when all of them peer with Equinix route server.
Even when IPv4 route fine, it go an extra hop to Axclusive instead of directly to EN Technologies.
I think your next step is limited.
Your friend might have more option since he has an IP Transit relationship with his upstream. Maybe get him to file a complaint?
His upstream (AS133210 EN Technologies) will then file another complain to upstream (AS132337 Axclusive)
None of these people has a Looking Glass so I think for now there is nothing more to investigate.
EDIT 2:
I have high confidence 2001:e68::e:fd0b is physically located in Etisalat SmartHub Fujairah. So this is the root cause of all the problem. TM egress the traffic physically in UAE and not Singapore.
EDIT 3:
I root cause Etisalat IPv6 routing loop problem. It's a configuration error where the next hop address is the same as the loopback address. That guy must be half asleep and mix up the ssh session of different router.
CODE
BGP neighbor is 2001:8f8::36, remote AS 8966, local AS 8966, internal link
BGP version 4, remote router ID 195.229.0.36
BGP state = Established, up for 51w0d13h
Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised
Address family IPv6 Unicast: advertised and received
Message statistics:
Inq depth is 0
Outq depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 0 205308908
Keepalives: 511403 7
Route Refresh: 0 1
Capability: 0 0
Total: 511404 205308917
Minimum time between advertisement runs is 5 seconds
For address family: IPv4 Unicast
Community attribute sent to this neighbor(both)
Outbound path policy configured
Route map for outgoing advertisements is *deny-out
0 accepted prefixes
For address family: IPv6 Unicast
Community attribute sent to this neighbor(both)
209412 accepted prefixes
Connections established 1; dropped 0
Last reset never
Local host: 2001:8f8:0:10:0:22:209:2, Local port: ???
Foreign host: 2001:8f8::36, Foreign port: ???
Nexthop: 195.229.3.210
Nexthop global: 2001:8f8:0:10:0:22:209:2
Nexthop local: ::
BGP connection: non shared network
Read thread: on Write thread: off
Your problem will be fixed if either:
1. TM don't egress in UAE
2. Etisalat put the correct IPv6 address in their next hop
This very comprehensive report.
I have asked my friend about Route issue, and I have verify with my another friend who use TIME and indeed route is correct.
hell, just now MCMC called me, my report sub category going to change to "Service Delivery". So proper team will investigate that TM did not fulfill RFC 6177 and blocking NPTv6/NAT66
Do you think there is hope to have proper IPv6? MCMC just updated and I mention about ISP can get free IPv6 subnet