more-specifics via IX

Thu Oct 18 17:57:17 UTC 2007

On 17 Oct 2007, at 20:55, Bradley Urberg Carlson wrote:

>
> 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.

Okay but:

1. Your customer/customer's customer is the one doing the broken  
routing here not you.. if he wants to be grumpy you should point him  
in the direction of the guy who is announcing the bad routes in the  
first place!

2. If I'm following this, your peer pays your customer? So you are  
peering with your customer's customer? If that was me I would either  
depeer them or tell them that you have an issue and need it resolving  
urgently or you my depeer them.

You're not the bad guy here ;)

>
>> 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.

wow, i think i need a diagram!! :P

i don't like sloppy networking, i would depeer anyone who i find is  
not up to my standards on what makes a 'peer'. this doesnt happen  
very often but if we want to educate people you can try talking and  
if that fails take action.

>
> 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.

not really, its pretty unusual. now that i understand the picture  
better tho i think you dont want to be filtering.. 90% of people  
won't peer with downstreams to avoid this kind of issue.. either you  
need to do that too or you need to make them fix it (if your peering  
is valuable to them they will do it)

don't forget they are getting a free lunch here, and that is  
unacceptable. if they are intentionally stealing your bandwidth then  
that is a major problem, if its an accident then you really should  
take action and insist they fix it. immediately and temporarily  
dropping the peering would be a good option

Steve