Re: more-specifics via IX
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
Re: more-specifics via IX
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
Re: more-specifics via IX
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
Re: more-specifics via IX
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
Re: more-specifics via IX
-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 iD8DBQFHFJMlSo7fU26F3X0RAqYLAJ9suyoqQ5Q9qU6lJKaaH0imAznsUACgxKxk CDM0aL0Ij32L5By3lnVjFuQ= =CgYZ -END PGP SIGNATURE-
Re: more-specifics via IX
[EMAIL PROTECTED] wrote on 10/15/2007 01:09:08 AM: 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?
Re: more-specifics via IX
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?
Re: more-specifics via IX
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. Wolfgang -- Wolfgang Tremmel e-mail: [EMAIL PROTECTED] DE-CIX Management GmbH Phone: +49 69 1730 902-26 Lindleystr. 12, 60314 Frankfurt Mobile: +49 173 340 4833 Geschaeftsfuehrer Harald A. SummaFax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln PGP.sig Description: Signierter Teil der Nachricht
Re: more-specifics via IX
On Oct 15, 2007, at 7:41, Wolfgang Tremmel [EMAIL PROTECTED] 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.
Re: more-specifics via 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 On 10/15/07, Wolfgang Tremmel [EMAIL PROTECTED] 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. Wolfgang -- Wolfgang Tremmel e-mail: [EMAIL PROTECTED] DE-CIX Management GmbH Phone: +49 69 1730 902-26 Lindleystr. 12, 60314 Frankfurt Mobile: +49 173 340 4833 Geschaeftsfuehrer Harald A. SummaFax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln
Re: more-specifics via IX
On 15 Oct 2007, at 13:33, John Payne wrote: 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 customer's customer is still going to see *your* routes via the MLP, unless (without knowing what exchange) you can attach a community to the announcement that forbids the route-server from propagating it to specific networks.
Re: more-specifics via IX
On Mon, Oct 15, 2007, Wolfgang Tremmel 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. you should honor your customers routing policy and simply accept the routes. Ah, stealing transit 101. How I love thee. Adrian
Re: more-specifics via 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 | | [EMAIL PROTECTED] http://he.net | +---+
Re: more-specifics via IX
On Oct 15, 2007, at 9:48 AM, Mike Leber wrote: 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. In this case it's his customer's customer... so no answer _necessary_ (as I've learnt from experience)
