more-specifics via IX

I have a few customers' customers, who appear at a local IX.
 Due to 
the MLPA-like nature of the IX, I hear their prefixes both
at the IX 
and via my own transit customers.  I normally use localpref
to prefer 
customer advertisements over peers' advertisements.

There is a customer's customer who is advertising
more-specifics at the 
IX (and using a different source AS, to boot).  I can think
of a couple 
ways to prevent hearing these, but thought I should ask for
suggestions 
first.

-Bradley

On 15-okt-2007, at 7:09, Bradley Urberg Carlson wrote:

> There is a customer's customer who is advertising
more-specifics at  
> the IX (and using a different source AS, to boot).  I
can think of  
> a couple ways to prevent hearing these, but thought I
should ask  
> for suggestions first.

What exactly is the problem?

On Oct 15, 2007, at 7:41, Wolfgang Tremmel
<wolfgang.tremmelde- 
cix.net> wrote:

>
> Am 15.10.2007 um 07:09 schrieb Bradley Urberg Carlson:
>
>>
>> I have a few customers' customers, who appear at a
local IX.  Due  
>> to the MLPA-like nature of the IX, I hear their
prefixes both at  
>> the IX and via my own transit customers.  I
normally use localpref  
>> to prefer customer advertisements over peers'
advertisements.
>>
>> There is a customer's customer who is advertising
more-specifics at  
>> the IX (and using a different source AS, to boot). 
I can think of  
>> a couple ways to prevent hearing these, but thought
I should ask  
>> for suggestions first.
>>
>
> you should honor your customers routing policy and
simply accept the  
> routes.

Whilst it is nice to accept a downstream of a downstream's
routing  
policy like that I don't think it is your place to say that.
The other  
response asking what the problem is also is a good example
of the  
misunderstanding of problems with the shim6 solution
although at a  
different place in the network. If MY policy is to send all
customer  
traffic through my customer connections, I should be able to
do that.

To answer the OP's question I'd be looking at manually
filtering the  
more specifics if they are also sending the aggregates
through the IX.

On Mon, 15 Oct 2007, Bradley Urberg Carlson wrote:
> I have a few customers' customers, who appear at a
local IX.  Due to 
> the MLPA-like nature of the IX, I hear their prefixes
both at the IX 
> and via my own transit customers.  I normally use
localpref to prefer 
> customer advertisements over peers' advertisements.
> 
> There is a customer's customer who is advertising
more-specifics at the 
> IX (and using a different source AS, to boot)

Time to time you will see this.

You could also hear the more specifics from another peer
that is one of
their transit providers or you could hear them via one of
your transit
providers.

> I can think of a couple ways to prevent hearing these,
but thought I
> should ask for suggestions first.

You can do all kinds of things to other network's routes
especially when
those routes aren't from your customers and what you are
doing doesn't
break connectivity (or solves a capacity problem and
improves
connectivity).  However, if you tweak routes of a paying
customer then you
will need to consider what your answer to your customer will
be for
overriding their traffic engineering.

Mike.

+----------------- H U R R I C A N E - E L E C T R I C
-----------------+
| Mike Leber         Wholesale IPv4 and IPv6 Transit      
510 580 4100 |
| Hurricane Electric     Web Hosting  Colocation            
    AS6939 |
| mleberhe.net                                           http://he.net |
+-----------------------------------------------------------
------------+

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bradley Urberg Carlson wrote:
> 
> I have a few customers' customers, who appear at a
local IX.  Due to the
> MLPA-like nature of the IX, I hear their prefixes both
at the IX and via
> my own transit customers.  I normally use localpref to
prefer customer
> advertisements over peers' advertisements.
> 
> There is a customer's customer who is advertising
more-specifics at the
> IX (and using a different source AS, to boot).  I can
think of a couple
> ways to prevent hearing these, but thought I should ask
for suggestions
> first.

I have seen the opposite of this as well. ISP X announces an
aggregate
at the local IX, but has some more specifics announced to
the transit
providers for TE needs. To avoid sending/receiving traffic
over transit
links and prefer peering route, they were suggested to also
announce
their more specific to their peers.

In your case, if your customer's customer is multihomed,
they might be
announcing more specific in line with their own routing
policies. If you
don't like it - then you'd setup a specific filter,
resulting most
probably in asymmetrical routing.

thanks
 - gaurab

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFHFJMlSo7fU26F3X0RAqYLAJ9suyoqQ5Q9qU6lJKaaH0imAznsUACg
xKxk
CDM0aL0Ij32L5By3lnVjFuQ=
=CgYZ
-----END PGP SIGNATURE-----

On 15 Oct 2007, at 03:49, Iljitsch van Beijnum wrote:

>
> On 15-okt-2007, at 7:09, Bradley Urberg Carlson wrote:
>
>> There is a customer's customer who is advertising
more-specifics  
>> at the IX (and using a different source AS, to
boot).  I can think  
>> of a couple ways to prevent hearing these, but
thought I should  
>> ask for suggestions first.
>
> What exactly is the problem?

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

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)

if you think it is malicious, you may want to hit them with
something  
official (IANAL)

Steve

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

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

Stephen Wilcox wrote:
> 
> 
> 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!

s/broken// and s/bad//

'broken' and 'bad' are all a matter of perspective here.

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

It's an MLPA policy based exchange (and probably just using
a central 
route-server) not bi-lateral peering.  De-peering isn't
possible here.

It's not an excuse for lack of filters, but as the OP
pointed out, the 
filters weren't expecting the routes from their customer's
customer.

-david