Google local peering starting (slowly)

Google now serves [almost] all traffic to TENET sites directly from either:

• peering connection, or
• some sort of GGC-like nodes [Google Maps, YouTube videos]
  

Name resolution and tracerouting from UCT hosts confirms that all Google services are being served from local [South African] servers. This has huge implications in bandwidth savings, and quality of user interaction because of lower latency for content that is already available on the local datacenter and caches.

Issues
Strangely, while www.youtube.com resolves to a locally-hosted server (64.233.179.100 currently), youtube.com (with no leading www.) resolves to a 208.65.153.xxx address, seemingly in Richmond, VA.

Clarification
The caching nodes [presumably GGC nodes] currently serve only certain services (map tiles, YouTube videos) and are generally co-located within a client network. The other Google services are served from machines located in Cape Town (based on ping times) and that are administratively within a Google-owned IP block.

Further clarification
Assume this is a "small" trial run (limited number of users on TENET, maximum goodwill from helping the poor academics) before a full roll-out. The caching nodes already save TENET up to 45 Mbps international transport! There is no local visibility to Google's ZA IP block from IS's route server.

gov.za proxy fail

The *.gov.za services that are proxied behind iproxy1.gov.za all seem to have fallen over, while the services that are proxied behind iproxy2.gov.za seem to be fine:

iproxy1
cemis.wcape.gov.za
www.westerncape.gov.za
www.services.gov.za
www.search.gov.za

iproxy2
www.gov.za
www.info.gov.za

Could be a proxy issue, or maybe Telkom playing games again, or even a local failure. Weiiiird.

ASN fail by default

Ahhh TENET, you continue to be the source of interesting and alternately amusing/depressing news:
[from the REN-news mailing list]

As of the 1st of January, all the Region Internet Registries (RIR's),
that being, AfriNIC, APNIC, LACNIC, RIPE and ARIN have adopted a policy which allocates 32bit ASN's by default
...
[A]lmost no networking equipment out there
currently supports these.
...
This means that should you get a 32bit ASN instead of a 16bit ASN, it
will not be useable to peer with or announce to the TENET network or
most other networks at this point.

I suppose this is a bit like the USG jump-starting DNSSEC by requiring it be present for the .gov TLD. But only a little bit, because in this case the pressure on the vendors is going to be coming from annoyed customers.

And since there's no backwards-compatibility built-in (no fall-back number), Metcalfe's Law works against one here: everyone you need to peer with also needs updated equipment and/or software.

Surprise surprise

So it turns out that some people have been using the looming spectre of the 2010 Soccer World Cup to help talk up their projects.

Infraco - I'm talking about you!

It's not that surprising, really. What is interesting is the talk of SAT-3 (amusingly and unintentionally further abbreviated as at-3) being upgraded to 320 Gbps. This will at least help Telkom with some extra bandwidth - 120 Gbps was pretty paltry at introduction and now looks downright anemic. Does Telkom dominate the SAT-3 consortium so much that it can just force the upgrade?

Gro'in' pains

Enough 80's references, let's skip to the meat of this post (so to speak). This is from a recent traceroute; DataHop might want to rename one of their nodes to accomodate some expansion in their traffic:

11 196.32.209.25 (196.32.209.25) 165.620 ms 160.809 ms
12 ge2-20-0-cr0.tch.uk.as6908.net (78.41.155.161) 236.578 ms 198.183 ms
13 te-4-2.r00.londen05.uk.bb.gin.ntt.net (83.231.146.69) 151.840 ms 153.098 ms

Unscheduled scheduled outages

A recent posting to the TENET ren-news list:

All Neotel MPLS GEN3 sites experienced a number of service failures
early yesterday morning. It appears that these were caused by Neotel
maintenance, of which TENET was not informed in advance.

even given

The Service Level Agreement provides that: "...The Providers will give TENET four days' advance notice of planned maintenance."

Let's hope Neotel doesn't become Neotelkom [the new Telkom?] :)

GEN3 failure

And so soon after the start of the service?

Hmmm, what does the SLA say about this? 99% uptime implies 1% downtime.

365 days x 24 hours x 1% = 87.60 hours down per year.

So they have loads of downtime left - bah humbug.

A quick estimation from the ML Sultan campus of DUT:


The interruption starts around 19h30 on the 5th of March, and lasts until about 09h30 on the 6th of March. That's 14 hours total. Ouch.

So we can look forward to another 73.6 hours of downtime. That's another 3 days left!

A companion blog

Dear faithful reader[s],

The Daily Fail, a new companion blog, has been started in order to keep up with the huge amount of stupidity out there in the dangerous world.

Please be careful. Regular reading of The Daily Fail will help you avoid becoming a statistic. Except that you'll be statistically more likely to read The Daily Fail: