[100124] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: more-specifics via IX

daemon@ATHENA.MIT.EDU (Bradley Urberg Carlson)
Wed Oct 17 22:58:11 2007

In-Reply-To: <EEEC0CBD-A476-407D-A210-FC8FDD59177A@packetrade.com>
Cc: nanog@merit.edu, Iljitsch van Beijnum <iljitsch@muada.com>
From: Bradley Urberg Carlson <buc@visi.com>
Date: Wed, 17 Oct 2007 21:55:25 -0500
To: Stephen Wilcox <steve.wilcox@packetrade.com>
Errors-To: owner-nanog@merit.edu


Thanks for the suggestions.

On Oct 17, 2007, at 6:06 PM, Stephen Wilcox wrote:
> well.. the problem of course is that you pull in the traffic from the 
> aggregate transit prefix which costs you $$$ but then you offload it 
> to the customer via a peering link for which you are not being paid

A bigger problem is that my IX peer pays less to my customer for 
transit.  If my customer notices that transit traffic has been going 
around him, he may be grumpy.  I prefer happy customers.

> its a pain but you cant stop the customer from doing it.. you can 
> however filter your customers prefix at the IX (an ASN filter would be 
> easiest)

In this case, the IX peer had let their transit provider (my customer) 
source the routes, then later advertised their own routes at the IX 
using their own ASN (so inconsistent source-as, and my as-path filter 
missed them).   I don't think they were trying to steal bandwidth; just 
sloppy networking.

I can either build a big import filter, dropping routes offered to me 
at the IX that are subnets of routes advertised to me by my transit 
customers (doesn't scale); or just audit customer routes versus peer 
routes periodically, looking for "bandwidth stealers".  It sounds like 
that is the usual approach.


-Bradley


home help back first fref pref prev next nref lref last post