I think the most pragmatic solution on your end is to have local preference the same for akl-ix and ape and use bgp weight so that for the same as-length it'll prefer akl-ix. the hops with vocus in them should have an extra asn in the path, and if it was just a prepend it'd be even between ape and vocus/akl-ix. i think it's semi-reasonable that things behave like they do. "it's just the way it is". Ben. On Fri, Dec 12, 2014 at 12:22:13PM +1300, Dave Mill wrote:
Hi all (Note, I'm not trying to place blame at any party here. Just interested in people's thoughts on this situation) We, Inspire/AS17705, recently peered at AKL-IX. I was interested in using this peering exchange as much as possible so we have tended to prefer AKL-IX routes over any other peering exchange (though we still prefer bi-lats, private interconnects, etc, over AKL-IX). Simple stuff.. We learnt a lot of routes off AKL-IX. We started sending traffic out via. AKL-IX. Cue customer complaints. In general, we were sending all traffic to AS4826/Vocus out via AKL-IX. I believe if another ISP had Vocus as an international provider the traffic would ingress that ISP via their international pipe. This led to one customer having packet loss over a VPN (I'd assume the far end had congested international) and another customer getting billed for this traffic as international. We ceased learning Vocus routes from the AKL-IX. Problem solved... Except, this doesn't really sound ideal to me. If Vocus are announcing routes to AKL-IX (their choice) I would like to be free to use them. What should we be doing in a situation like this? What should Vocus be doing? Am I just making a mountain out of a molehill here and should I just shut-up and leave my current fix in place? Cheers Dave
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog