Problem it is very slow
Traceroute from UTM to other sites (e.g. www.unimas.my) takes over 45 seconds just to get to the 4th hop. See the measurements.
It times out at 60 seconds and only gets to the 5th hop. All 5 hops are in the UTM autonomous domain.
Executing exec(traceroute, -m 30 -q 3, 216.8.177.28, 140) traceroute to 216.8.177.28 (216.8.177.28), 30 hops max, 140 byte packets 1 161.139.68.250 (161.139.68.250) 1.005 ms 1.328 ms 1.555 ms 2 10.110.1.67 (10.110.1.67) 1.063 ms 1.429 ms 1.367 ms 3 161.139.248.254 (161.139.248.254) 3.175 ms 2.616 ms 3.037 ms 4 161.139.244.65 (161.139.244.65) 3.157 ms 3.367 ms 2.649 ms 5 161.139.245.254 (161.139.245.254) 3.680 ms 3.649 ms 3.565 ms
The RTT is < 4 ms in all cases. So for 3 probes/hops and < 4ms RTT/probe and 5 hops we would expect < 60msec, this is a factor of 75 < the 45sec timeout to just get the 4th hop. This is repeatable and does not depend on time of day.
A possibility is the name resolution. We tested this with the -n option. This helps by between 9 and 15 seconds for each name that needs resolving.
Other things we can do to speed the traceroute up include: start at ttl 6 (-f 6, default 1), only do 1 query/hop (-q 1, default 3), only wait 3 seconds for each probe (-w 3, default 5). It appears that apart from starting at the 6 hop (which reduces the names to be resolved by 5), these do not help by much.
UTM is running Linux 2.6
saqibali@saqibali-desktop:~$ uname -a Linux saqibali-desktop 2.6.32-45-generic #102-Ubuntu SMP Wed Jan 2 21:53:06 UTC 2013 i686 GNU/Linux
Looking at the man pages the traceroute is able to lookup the Autonomous System information (-A option) and also to send queries in parallel (-N squeries option).
We also made measurements of timing for traceroute from UTM to UNIMAS starting at hop 1, with and without the -A option and with and without name resolution (-n option) . With name resolution the traceroute took over 3 minutes, Without name resolution it took 30 seconds. The number of names that needed resolving was 10. Thus each name took roughly 15 seconds to resolve.
Traceroute UTM to UM goes via the US
The interesting traceroute is the one from UTM to UM. It takes > 280ms and goes via the US. This needs to be investigated. It should not go via the US. It looks like the peering needs attention.
BTW ping (i.e. end-to-end) from UM=>UTM is ~15ms and is similar from UTM=>UM, so the traceroute makes little sense.
The trace route from UM to UTM (http://pinger.fsktm.um.edu.my/cgi-bin/traceroute.pl?target=www.utm.my) looks more sensible though it does not complete. The last hop reporting is at IP address 161.139.192.4 which is in ASN TTNET-MY