Hi Mark,

 

The CallPlus node is open to anyone at APE and we were sitting on it happily until our upstream provider Kordia changed from PacNet to Vocus.

 

 

Cheers

 

--

Tristram Cheer
Network Architect - Most problems are the result of previous solutions...

Description: C:\Users\tristramc\AppData\Roaming\Microsoft\Signatures\Uber Simple (Tristram Cheer)-Image01.jpg

Tel. 09 438 5472 Ext 803 | Mobile. 022 412 1985 | 53 Port Road, Whangarei 
tristram.cheer@ubergroup.co.nz |www.ubergroup.co.nz

Description: C:\Users\tristramc\AppData\Roaming\Microsoft\Signatures\Uber Simple (Tristram Cheer)-Image02.png  Description: C:\Users\tristramc\AppData\Roaming\Microsoft\Signatures\Uber Simple (Tristram Cheer)-Image03.png

From: nznog-bounces@list.waikato.ac.nz [mailto:nznog-bounces@list.waikato.ac.nz] On Behalf Of Mark Foster
Sent: Tuesday, 28 February 2012 10:49 a.m.
To: nznog@list.waikato.ac.nz
Subject: Re: [nznog] Async Routing across ape to pipe return via vocus &Internode speedtest

 


The problem with doing this is that Callplus may not be intending their Akamai node to be used by folks that aren't either their customer, or an organisation they have a commercial arrangement with to serve this content.

In my last job we had a similar issue, we were going to wind up requiring our upstream to do some source-based-routing, so we didn't pursue that option as it wasn't considered practical.

Instead perhaps ISP's need to consider setting up their own Akamai presence or formally arranging something with an ISP that does have it. (And inversely the ISPs that want to enforce this position would need to apply controls on their DNS server, which is itself annoying for other reasons...)

Mark.


On 28/02/12 10:09, 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@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@list.waikato.ac.nz [mailto:nznog-bounces@list.waikato.ac.nz] On Behalf Of Tim Price
Sent: Tuesday, 28 February 2012 9:59 a.m.
To: 'Barry Murphy'; nznog@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@list.waikato.ac.nz
[mailto:nznog-bounces@list.waikato.ac.nz] On Behalf Of Barry Murphy
Sent: Tuesday, 28 February 2012 9:53 a.m.
To: nznog@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@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
 
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog