Re: [nznog] Async Routing across ape to pipe return via vocus &Internode speedtest

Hey Macca, Because we use vocus for transit, we seem to be getting priority to vocus akamai. Are you able to tell us what the IP address of the local nodes so we can possibly add fake latency to these nodes to try and swing the traffic to the APE and or our local transit provider (cheaper). The problem we are having is our local transit provider has their Akamai infrastructure in CHCH, the latency to this cluster would be a lot higher than that of the vocus locally hosted option. Alternatively can we possibly have an additional community to tag that we can stop the advertising of our ranges to Auckland cluster & Sydney Cluster, this way we can manage the traffic in a much better arrangement. Perhaps you can add this communities to the existing list at http://tools.vocus.com.au/additionals/communities2.0.html for all providers to use so they can swing traffic as they wish. Many thanks Barry On Tue, 28 Feb 2012 10:36:24 +1100, McDonald Richards wrote:

Hello,

I seem to remember our operations team doing work to assist you in moving traffic from the Vocus network on to APE Tristram. We by no means told you to "sod off" and remain, as always, happy to assist where we can.

We installed an Akamai cache to serve our customer routes in Auckland after we noticed a significant number of hits on our Sydney infrastructure coming from New Zealand. This traffic, combined with load spikes we would see when a local NZ cache ran into problems was enough to motivate us to put a local node in to try and keep the traffic closer to the end users.

If I recall correctly, the load and performance of a cache is one of the metrics used in the selection. If the "free" (and I use this term very loosely as this infrastructure does cost money to run) node at CallPlus was under strain, then Akamai, whose own agreements with their content customers probably have some sort of metric for performance, would likely elect to send you to another available cache to ensure their content is delivered in line with their commercial obligations.

All of our transit routes are advertised to Akamai as eligible for access to caches on our network. This is a standard route policy that exists to cover the costs of running the node (by generating some utilisation) and to ensure that if there are any downstream node failures that we are able to absorb the impact within the country (with a slight uplift in traffic required to fill the cache instead of the traffic being served from further abroad).

Macca Vocus

On 28/02/12 8:09 AM, "Tristram Cheer" wrote:

...

Hey All,

We had the same issue last year, Akamai decided to point us at Vocus's node and Akamai traffic coming from AKL server's under Vocus's control were returning our data over our International. We of course were very unhappy about this but we got nowhere with Vocus or Akamai about it (Basically told to sod off), The only way we found to fix it was to point the DNS zones for akamaitech.net and akamai.net to another DNS server in NZ that stayed pointed to CallPlus's Akamai node.

Very frustrating given and difficult to resolve, The offending parties always seem to be of zero help in these sorts of cases.

Cheers

--

Tristram Cheer Network Architect

Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985 Fax. | tristram.cheer(a)ubergroup.co.nz | www.ubergroup.co.nz

PS: Follow us on facebook: www.ubergroup.co.nz/fb or twitter https://twitter.com/#!/ubergroupltd -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Tim Price Sent: Tuesday, 28 February 2012 9:59 a.m. To: 'Barry Murphy'; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Async Routing across ape to pipe return via vocus &Internode speedtest

I've seen something similar to this whereby traffic to Vocus egresses APE and ingresses International via Kordia. I was told by various parties that it is because Vocus sets a higher local preference on it's 'customer' routes (Kordia being a customer of Vocus) than on the peering exchanges. The only way that we could force the routes to be synchronous again was to drop all Vocus routes received across APE which would seem counter productive.

-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Barry Murphy Sent: Tuesday, 28 February 2012 9:53 a.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Async Routing across ape to pipe return via vocus & Internode speedtest

Hey Guys,

I just saw Glen Eustace's post which reminded me of an issue we have seen of late with regards to 'my internet seems slow'. Just wondering if anyone else has seen this similar issue since PIPE joined the APE, then again it's not just PIPE, but a mixture of Oz providers accepting traffic over the APE and then returning the transit via international links such as Vocus.

I have a few customers that buy dedicated international and dedicated domestic bandwidth. These customers have a stub address that resides in the Domestic VRF & another stub in the International VRF. Since PIPE came on-board we have noticed that customers trying to do a whois (whois.apnic.net) using their router that connects the stubs, that the traffic goes out thinking its Domestic, but then gets no response because it attempts to return in via the International (Transit) VRF to which has no access to stubs in the Domestic VRF.

Another issue we see where 'slow' comes into play is internode have recently been added to speedtest.net as a NZ speedtest server in Auckland. While tracing to this node it does appear to go across APE, the return path is via Vocus. When a customer attempts a speed test and they see they are only able to obtain say 30mbps rather than the 100mbps they would expect from a "NZ" server they start thinking something is broken, when actually it's because the server is International and they are in a pool of bandwidth.

I've tried to contact internode & so has a colleague of mine but with no luck. We've tried to pre-pend AS's to the vocus communities but again this hasnt helped at all.

Just wondering if anyone else has seen issues arise since ASYNC routing between Oz & NZ, to do with either STUBs getting no internet due to VRF nature, or these 'slow' speeds being reported.

thanks Barry

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog