High lag caused here in SA?

[Arzy]

As mentioned a couple of times now I like to play MUD's based in the US. Now for those who don't know the term, its text based gaming using Telnet and requires a half decent connection in regards to packet loss and latency. The end of the month kills this off, but what I found remarkable today while staring at a traceroute to the server I play on is that, while the hops from server to server in the US are rather constant, there is a huge hop right here in south-africa of about 300ms.

1 192.168.10.200 ? 2
2 165.165.128.1 rndf-128-01.telkomadsl.co.za 17
3 196.43.10.181 rndf-ip-er-2-fe-12-0-1-1.telkom-ipnet.co.za 14
4 196.43.9.146 ash-ip-dir-equinix-pos-5-0-1.telkom-ipnet.co.za 356
5 208.49.224.161 so-3-0-1.ar1.DCA3.gblx.net 505
6 67.17.68.106 pos0-0-0-155M.ar1.CLE1.gblx.net 520
7 208.50.254.26 APK-NET.fe-2-2-2.102.ar2.CLE1.gblx.net 529
8 216.130.10.229 p3-0-0.cr1.halle.clevoh.e-xpedient.com 516
9 216.183.174.134 g1-1.cr2.halle.clevoh.e-xpedient.com 536
10 216.183.176.190 f48.ar4.halle.clevoh.e-xpedient.com 559
11 66.181.87.160 ? 582 0:0:Echo Reply

 

[stoke]

010 ms rndf-128-01.telkomadsl.co.za
010 ms rndf-ip-er-2-fe-12-0-1-1.telkom-ipnet.co.za
340 ms ash-ip-dir-equinix-pos-5-0-1.telkom-ipnet.co.za
541 ms so-3-0-1.ar1.DCA3.gblx.net
551 ms pos0-0-0-155M.ar1.CLE1.gblx.net
651 ms apk-net.fe-2-2-2.102.ar2.cle1.gblx.net
531 ms p3-0-0.cr1.halle.clevoh.e-xpedient.com
551 ms g1-1.cr2.halle.clevoh.e-xpedient.com
561 ms f48.ar4.halle.clevoh.e-xpedient.com
561 ms 66.181.87.160
Yip - my guess is that we have located the shaping server.
I love the 10ms lag at the first hop.
Who has a tool that can "ping" using port 80 ?

The more you know - the worse it gets.

 

[loosecannon]

sad thing is it appears mywi have asked SAIX for help with BW management so i guess they will be lagged aswell based on this ...

 

[Deckert]

<i>Originally posted by stoke:

340 ms ash-ip-dir-equinix-pos-5-0-1.telkom-ipnet.co.za

Yip - my guess is that we have located the shaping server.
</i>

That IP (196.43.9.146) is already overseas. Here's a some ping times from an overseas router to that IP. Clearly it is local to the US or UK.

---
Sending 5, 100-byte ICMP Echos to 196.43.9.146, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/176/180 ms
---

--deckert

 

[Echo]

Running a NeoTrace on the above IP (196.43.9.146) shows the location as Cape Town, my guess is it is the last stop before international.

 

[Deckert]

<i>Originally posted by Echo:
Running a NeoTrace on the above IP (196.43.9.146) shows the location as Cape Town, my guess is it is the last stop before international.
</i>
Yup, it's a common error for NeoTrace. It bases its location information on the zone allocations in the ARIN database (www.arin.net). Since that netblock was registered by Telkom with a location of CT, NeoTrace will mistake any IP in that netblock to be in CT.

Telkom has to provide interface IPs to the routers in new york, so they take it from their own netblocks. You'll see that Neotrace makes the same mistake with IS as well:

---snip---
3 168.209.89.53 (168.209.89.53) 1.383 ms 0.651 ms 0.751 ms
4 core2b-rba.nmszone.is.co.za (196.26.0.9) 1.019 ms 0.981 ms 1.149 ms
5 168.209.0.86 (168.209.0.86) 262.731 ms 263.956 ms 264.066 ms
6 core1b-ny.nmszone.is.co.za (168.209.244.3) 264.962 ms 326.188 ms 264.415
---snip---

You can see that 168.209.244.3 is in NYC in the US, but the IP falls within the DimensionData/IS netblock and hence the location is given as JHB.

--deckert