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
What exactly is the problem?
you should honor your customers routing policy and simply accept the routes.
Wolfgang
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.
The problem is you’re announcing the aggregate prefixes of your customer’s customers to your upstream providers and the traffic from your upstreams to those networks will be routed through the IX (instead of your customer connection) because of the longer prefix effect and so you’re not charging the traffic and you’re losing revenue!!!
I think in this case, you have to filter all those prefixes learnt from the IX.
Che-Hoo
Ah, stealing transit 101. How I love thee.
Adrian
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 -----------------+
In this case it's his customer's customer... so no answer _necessary_ (as I've learnt from experience)
-----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
>
> 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
>
>
>
Sounds like misconfiguration. Have you tried contacting them and explaining 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.
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
Thanks for the suggestions.
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!! 
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:
Thanks for the suggestions.
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