Can someone who is in favor of implementing filters explain to me why slicing a /16 into 16 /20's is any different than slicing a /20 into 16 /24's?
with the understanding that i'm explaining why MIBH did it rather than explaining why you should do it (if indeed you should, which is not even a conversation i could find myself in), the reasoning is/was as follows. there has to be a limit. that's all. that's the full extent of the reasoning. some limit has to be chosen, because without limits, human nature kicks in and "the people" start voting themselves bread and circuses. i'm not interested in going down that path because it's a recipe for _finding_ the limits of the global routing system, both in table size and in delta volume. (we'd find it when the 200,000th /32 was injected, and by that time it would be hard to reverse course.) so there's going to be a limit. the number of routes allowed into a router shall be non-infinite. that limit can be selenforced in a number of ways: 1. total number of routes 2. total number of routes per peer 3. prefix length now, #1 would just be too unpredictable. which routes were present would depend on what order the peers came up. so, one day, some routes, the next day, some different routes. #2 is in fact in wide use, but as an error ceiling to keep a peer from accidentally sending you a full table rather than as a way to apportion a router's resources. in a world which (clearly!) wants me to store 200,000 /32's, though, it's difficult to imagine how #2 helps prevent this. #3 is a gross hack which happens to have the nice properties of "predictable" (one day's routes will be much like another day's routes) and "minimal impact" (the long prefixes i'm throwing away almost always have shorter "covering" routes). and, #3 is negotiable per peer. abovenet allows its peers to send long prefixes because this makes "longest exit" possible. (this might or might not cause abovenet some scalability problems, but it's their decision and will impact noone except them and their customers.) some of you know that i had some involvement in both MIBH and abovenet and may be thinking of asking why these networks had different prefix filtering policies. two answers: MIBH wasn't a global network so "longest exit" wasn't going to be possible in any case; and MIBH didn't own any GSR's.
If the thought is "you're given a /20, i only want to see a /20.." then why doesn't "you're given a /18, I only want to see a /18" also apply?
because there's got to be some limit. if you want to set that limit at "you were given a /24 so i don't want to see any /28's from you", then fine. but obviously some trial and error has gone on here, and the folks who have prefix filters have set them so that (a) any longer and there'd be too many routes, and (b) any shorter and there'd be too much nonreachability. this is one of nature's equilibriums. it has shifted back and forth over time. the filter lengths verio is using are obviously in verio's best interests or they would have different ones.
I don't have any hard evidence to know how much of an impact this actually has, but I would be very interested to see how many more specific /19's and /20's exist in a "verio-filtered" table that were allocated as /16's and shorter.
i'm pretty sure verio has a looking-glass instance, so you can find out.
I don't have any hard evidence to know how much of an impact this actually has, but I would be very interested to see how many more specific /19's and /20's exist in a "verio-filtered" table that were allocated as /16's and shorter. i'm pretty sure verio has a looking-glass instance, so you can find out.
On Sat, Sep 29, 2001 at 09:09:19AM -0700, Randy Bush wrote:
I don't have any hard evidence to know how much of an impact this actually has, but I would be very interested to see how many more specific /19's and /20's exist in a "verio-filtered" table that were allocated as /16's and shorter. i'm pretty sure verio has a looking-glass instance, so you can find out.
any plans to follow up with long term data? of particular interest would be rate of growth: routing table as a whole vs prefixes allowed by the filters vs prefixes blocked by the filters. also interesting would be a more thorough data analysis (e.g. what portion of prefixes blocked by the filters are part of some aggregate already in the table/what portion actually represent loss of reachability) i'm sure the ubiquitous NANOG cheap peecee hardware(TM)[1] with reasonable code could blow through the data in a few seconds. we know filtering == smaller table, but what i (and maybe somebody else) really want to know is does filtering (in reality, not theory) == slower table growth? imho, the latter is of considerably higher strategic usefulness. forgive me if these questions have been asked/answered, but i missed it in the mire. 1. that hardware which we so often like to compare our routers to in terms of memory/processor power. (not an actual product of NANOG or lart.net or any other particular entity that i may or may not be associated with) party on, sam -- Sam Thomas Geek Mercenary
<http://psg.com/~randy/010521.nanog> any plans to follow up with long term data? of particular interest would be rate of growth: routing table as a whole vs prefixes allowed by the filters vs prefixes blocked by the filters.
On 29 Sep 2001, Paul Vixie wrote:
there has to be a limit.
A limit is needed, but the filtering method in question to me essentially says this: if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat as much as you want.. we feel this is an acceptable practice. Yet, if you're a legitimately multihomed customer wants to push out a single /24 (1 AS, 1 prefix) that is not considered acceptable. The only kind of prefix filtering I would want to implement is something that can accomplish: 1. Define threshold, say /20 or /18 or hell even /8. 3. all prefixes longer than threshold get held until entire tables are loaded 3. start looking at the longer prefixes across the entire ipv4 space starting with the longest and finishing at threshold+1 4. if prefixes longer than threshold appear as part of a larger aggregate block that *originate* from the same AS, drop. 5. if prefixes longer than threshold originate from a different AS than the aggregate, accept. This way I could get rid of redundant information yet at the same time not cause any trouble to smaller multihomed customers. I'm not saying that we should allow /32's to be pushed everywhere either. As you said there has to be a limit, and /24 seems to be a pretty good one if something along the lines of the above mentioned filtering algorithm could be used. I'm sure in reality there's many reasons this would not be able to be implemented (CPU load perhaps) but it would atleast do something more than a "gross hack" that nails some offenders, not all by any means, and impacts multihomed customers who are only a portion of the problem that the current prefix filtering solution does not solve. paul
Date: Sat, 29 Sep 2001 14:58:09 -0400 (EDT) From: Paul Schultz <pschultz@pschultz.com>
if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat as much as you want.. we feel this is an acceptable practice. Yet, if you're a legitimately multihomed customer wants to push out a single /24 (1 AS, 1 prefix) that is not considered acceptable.
Right.
The only kind of prefix filtering I would want to implement is something that can accomplish:
[ snip ] An interesting thought. Group BGP adverts / table updates by prefix length... get connectivity up and going, then chew on the smaller details as needed. Sort of like real-time process priorities; if you can get there, queue longer prefixes until _after_ all others have been processed.
This way I could get rid of redundant information yet at the same time not cause any trouble to smaller multihomed customers. I'm not saying that we should allow /32's to be pushed everywhere either. As you said there has to be a limit, and /24 seems to be a pretty good one if something along the lines of the above mentioned filtering algorithm could be used.
Seems to me that "saving the Internet" means strict ingress filtering[1] of downstreams and strict egress filtering[2] to peers and upstreams... which is pretty much the opposite of what Verio does. [1] Providers SHOULD filter/aggregate downstream routes, unless there's some overriding reason not to. There's enough bad BGP that trusting Joe Provider to do things right scares me. (I'm no <insert favorite NANOG routing superhuman guru> myself, but at least I know enough to speak decent BGP and to "tune" things.) [2] Want to tune inbound traffic? Fine... advertise those longer prefixes to your upstreams/peers. But don't make the rest of the Internet suffer. Communities good. Extra routes bad.
I'm sure in reality there's many reasons this would not be able to be implemented (CPU load perhaps) but it would atleast do something more than a "gross hack" that nails some offenders, not all by any means, and impacts multihomed customers who are only a portion of the problem that the current prefix filtering solution does not solve.
Filter/aggregate as close to origination as possible. "Be conservative in what you send, and liberal in what you receive." Haven't I heard that somewhere before? (Bonus points for anyone who can name the RFC without wimping out and using a search like yours truly alas had to do.) Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
The only kind of prefix filtering I would want to implement is something that can accomplish:
[ snip ]
An interesting thought. Group BGP adverts / table updates by prefix length... get connectivity up and going, then chew on the smaller details as needed. Sort of like real-time process priorities; if you can get there, queue longer prefixes until _after_ all others have been processed.
assuming you're router can store, process and switch against n x million routes in real time .. suspect technology will take us there but you want to try and influence people to hold back, else we'll all suffer on the day the internet reaches critical mass and routes overtake technology and all providers routers give up!
Seems to me that "saving the Internet" means strict ingress filtering[1] of downstreams and strict egress filtering[2] to peers and upstreams... which is pretty much the opposite of what Verio does.
[1] Providers SHOULD filter/aggregate downstream routes, unless
Two different subjects? Filter definitely, you want to ensure quality and sanity. But aggregate... hmm, dont think that'll work with commerical people. A customer multihomes and you aggregate whilst a.n.other doesnt.. a.n.other gets all the traffic and you become the secondary provider and let a.n.other get all the new business as primary!
[2] Want to tune inbound traffic? Fine... advertise those longer prefixes to your upstreams/peers. But don't make the rest of the Internet suffer. Communities good. Extra routes bad.
but people dont advertise long prefixes in order to simply make use of two providers for the sake of it, they do it in order to create their own unique routing policies which by definition needs to be internet-wide i would envisage all kinds of problems too where the aggregating upstream accepts your specific routes via another isp by mistake and then your transit traffic ends up going all round the place.. you'd be advertising /24s to peers and all but one transit, with primary transit aggregating up to /16 or whatever, feels bad..
I'm sure in reality there's many reasons this would not be able to be implemented (CPU load perhaps) but it would atleast do something more than a "gross hack" that nails some offenders, not all by any means, and impacts multihomed customers who are only a portion of the problem that the current prefix filtering solution does not solve.
as i say, only one transit can aggregate, the other one cant unless they both assign blocks and one uses nat.. but then it gets ugly and eats up IPs Steve
Filter/aggregate as close to origination as possible.
"Be conservative in what you send, and liberal in what you receive." Haven't I heard that somewhere before? (Bonus points for anyone who can name the RFC without wimping out and using a search like yours truly alas had to do.)
Eddy
--------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence ---------------------------------------------------------------------------
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
-- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008
Date: Sat, 29 Sep 2001 21:09:49 +0100 (BST) From: Stephen J. Wilcox <steve@opaltelecom.co.uk>
[1] Providers SHOULD filter/aggregate downstream routes, unless
Two different subjects? Filter definitely, you want to ensure quality and sanity. But aggregate... hmm, dont think that'll work with commerical people. A customer multihomes and you aggregate whilst a.n.other doesnt.. a.n.other gets all the traffic and you become the secondary provider and let a.n.other get all the new business as primary!
Punch holes in aggs for multihoming, same as now. Maybe I should clarify... I was referring to splitting netblocks for the purpose of tuning traffic.
[2] Want to tune inbound traffic? Fine... advertise those longer prefixes to your upstreams/peers. But don't make the rest of the Internet suffer. Communities good. Extra routes bad.
but people dont advertise long prefixes in order to simply make use of two providers for the sake of it, they do it in order to
IGP-into-BGP causes this, and is hardly for preferring traffic from one upstream.
create their own unique routing policies which by definition needs to be internet-wide
Tag a single netblock with a community or MED. Don't split it into two longer prefixes. Of course, that might require inter-AS cooperation.
i would envisage all kinds of problems too where the aggregating upstream accepts your specific routes via another isp by mistake and then your transit traffic ends up going all round the place.. you'd be advertising /24s to peers and all but one transit, with primary transit aggregating up to /16 or whatever, feels bad..
Hmmmm. So I have customer X, who also connects to backbone B. They advert several blocks, which I agg to 192.168.0.0/19. B does not agg the blocks... but I'd also agg what I hear from B, into the same /19. No problem here. Or perhaps a hack... match ^[0-9]*_ and prefer it over longer prefixes. i.e., if you can get there directly, it's better than going through another AS. Your point definitely merits thought... but I'm not sure that it's insurmountable. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.
[2] Want to tune inbound traffic? Fine... advertise those longer prefixes to your upstreams/peers. But don't make the rest of the Internet suffer. Communities good. Extra routes bad.
but people dont advertise long prefixes in order to simply make use of two providers for the sake of it, they do it in order to
IGP-into-BGP causes this, and is hardly for preferring traffic from one upstream.
create their own unique routing policies which by definition needs to be internet-wide
Tag a single netblock with a community or MED. Don't split it into two longer prefixes. Of course, that might require inter-AS cooperation.
but if only one provider is agg'ing it will always prefer the most specific route regardless of tags
i would envisage all kinds of problems too where the aggregating upstream accepts your specific routes via another isp by mistake and then your transit traffic ends up going all round the place.. you'd be advertising /24s to peers and all but one transit, with primary transit aggregating up to /16 or whatever, feels bad..
Hmmmm. So I have customer X, who also connects to backbone B. They advert several blocks, which I agg to 192.168.0.0/19. B does not agg the blocks... but I'd also agg what I hear from B, into the same /19. No problem here.
no problem for you, but B's other peers wont agg and they will only see B's more specific path as valid
Or perhaps a hack... match ^[0-9]*_ and prefer it over longer prefixes. i.e., if you can get there directly, it's better than going through another AS.
Your point definitely merits thought... but I'm not sure that it's insurmountable.
i see where youre coming from but its not a part of bgp4. you could write it into bgp5, trouble is theres a lot of routes out there less specific and when you turn on this feature it could be very unpredictable. the other issue is you dont really want to prefer any route, you want them equally valid and how can you do that unless all the upstreams apply the same tags/rules theres only 20000 AS's, and its the AS that is defined as having a single routing policy not the prefixes. why cant internet routing be based on AS announcements, yeah i know you need to rewrite everything but i couldnt think of a better idea. :) Steve
On Sun, Sep 30, 2001 at 01:10:00PM +0100, Stephen J. Wilcox wrote:
theres only 20000 AS's, and its the AS that is defined as having a single routing policy not the prefixes. why cant internet routing be based on AS announcements, yeah i know you need to rewrite everything but i couldnt think of a better idea. :)
Smaller isps tend to not have consistent route announcements to all their upstreams. one path gets prepended while the other gets a different set of prefixes advertized due to the routes being more 'regionally close' within their own network, or for other policy reasons. ie: prefix with 5m traffic gets adverted out a link where they want to use a fixed-price transit circuit instead of a burst-measured circuit that has a higher per-mb/s cost. -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On 29 Sep 2001, Paul Vixie wrote:
so there's going to be a limit. the number of routes allowed into a router shall be non-infinite. that limit can be selenforced in a number of ways:
1. total number of routes 2. total number of routes per peer 3. prefix length
<sarcasm> #4 most-used/least-complaining Analyze NetFlow to determine where 80-90% of your traffic (by volume or flow-count) originates/terminates, build a filter to only accept those routes (or ASN's). Your route table would probably be 20% what it is now. Customers would fill out a Web form to request routing to filtered blocks, and the most popular requests would be added. You could do this for customer routes as well, so you only advertise the top 80-90% of customer routes, and tell the rest of your customers they don't use enough bandwidth to justify a route table entry. </sarcasm> Companies are paying money to get more, reliable bandwidth. There is value-add created by multi-homing that people are willing to pay for. Those who stand to most benefit from this demand are not the ma-and-pa ISPs, it's the same big companies who already own most of the market. Anything that stops the demand hurts them more than anyone else. Asymmetric filtering ("I won't accept yours, but expect you to accept mine") certainly get's people's attention, and if everyone filtered it would definitely make the problem go away, at least temporarily. But the market /will/ be satisfied, you can't permanently deny the demand for more, reliable bandwidth. Maybe before you could stop or slow down the train, I think it's likely now it'll run you over. As long as there isn't a solution that solves the problem, we'll keep having these same discussions, with different 'stupid' work-arounds. Asymmetric filtering does not solve the problem the market is willing to pay to solve. Progressive dampening and Multi6 look more promising. Consider where we would be now if the solution to address-space depletion was 'don't assign any more addresses'. Thank goodness for a solution (CIDR) that accomodated the demand in a way that was tolerable for most people. It wasn't exactly what the customer wanted (their own portable Class A), but it solved the problem well enough for most people. What solution will be analogous to CIDR in this situation? Pete.
participants (8)
-
E.B. Dreger -
Jared Mauch -
Paul Schultz -
Paul Vixie -
Pete Kruckenberg -
Randy Bush -
Sam Thomas -
Stephen J. Wilcox