Re: /24's run amuck?
Umm... because if you filter the /24s you will remove 58K of 95K, or some 61%. I'm *sure* that having a routing table 40% of the original size will help the next time you have a BGP flap.
Of course, some attentive customers MAY notice reachability issues with those 58K prefixes, but no big deal, at least the routing table is smaller. Heck, might as well go ahead and filter /23 and longer, that'll loss another ~10K, or better yet... :-) -danny
On Tue, 06 Feb 2001 15:07:10 MST, Danny McPherson <danny@ambernetworks.com> said:
Umm... because if you filter the /24s you will remove 58K of 95K, or some 61%. I'm *sure* that having a routing table 40% of the original size will help the next time you have a BGP flap.
Of course, some attentive customers MAY notice reachability issues with those 58K prefixes, but no big deal, at least the routing table is smaller. Heck, might as well go ahead and filter /23 and longer, that'll loss another ~10K, or better yet... :-)
Hey, I *said* your milage may vary. ;) And now for the *tough* question - of those 58K /24's, how many could be eliminated by more careful aggregation and filtering? I'm willing to bet that at least 25% are sites that have two connections to their provider, and are therefore advertised within the provider's net, and are simply escaping due to misconfiguration at the border. So - who wants to crunch the numbers and figure out how many of those 58K are useless punchouts ("Route all of 128.257.x.x to me, except for 128.257.219.x, which also goes to me").... Bonus points for identifying the AS that covers the greatest percentage of its address space with aggregable punchouts (although I'm willing to bet that there's some offenders out there with greater than 100% ;) Valdis Kletnieks Operating Systems Analyst Virginia Tech
Valdis.Kletnieks@vt.edu wrote:
And now for the *tough* question - of those 58K /24's, how many could be eliminated by more careful aggregation and filtering? I'm willing to bet that at least 25% are sites that have two connections to their provider, and are therefore advertised within the provider's net, and are simply escaping due to misconfiguration at the border.
So - who wants to crunch the numbers and figure out how many of those 58K are useless punchouts ("Route all of 128.257.x.x to me, except for 128.257.219.x, which also goes to me")....
Bonus points for identifying the AS that covers the greatest percentage of its address space with aggregable punchouts (although I'm willing to bet that there's some offenders out there with greater than 100% ;)
You might want to take a look at the aggregation possibilities I've been finding at http://www.mcvax.org/~jhma/routing/ (everything there is updated on a daily basis). Based purely on origin AS, for any AS where any form of aggregation could occur, it lists which new aggregates should be announced (in place of individual specific routes), and which should be withdrawn (your "useless punchout" case above) or advertised with a different origin (because all the address space covered is being announced with longer prefixes from another AS). Since today, there are also some pretty(?) pictures showing prefix length distribution from my view of the BGP table. Regards, James
* Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> [20010206 21:02]:
So - who wants to crunch the numbers and figure out how many of those 58K are useless punchouts ("Route all of 128.257.x.x to me, except for 128.257.219.x, which also goes to me")....
Uhm, except that many punchouts are done so that someone else can *originate* announcements for that block and control their own metrics. Likely the ASN announcing 128.257.x.x is one of those still transitting traffic for that punched out network, but they no longer are the origin for the more specific announcement. In this way, the utilizer of the more specific can do things like prepending or whatever they like. It is fairly common when someone multihomes with non-ARIN space. If they pull IP space from one of their upstreams, they need to be able to announce equally specific /x routes via both or suffer funky inbound traffic patterns. This isn't possible if the upstream the space is from doesn't do the punchout for them. Considering how many multihomed sites there are without justification for a </19 (or /20) how else do you suppose they gain control over their announcements? So a more accurate way to figure out how many of those 58K are useless punchouts would be to first ask for the ones that say "Route all of 128.257.x.x to me, except for 128.257.219.x, which also goes to me" then to see if 128.257.219.x is also being announced via any other transit providers. Unless I'm misreading the punchouts you are referring to. Additionally, it remains impossible to *truly* know the intent of someones routing policy without asking them. I mean, some people could have funky routing backup scenarios that routing announcements that look odd to all of us looking into their network. I'm not saying they are right or they are wrong -- I'm saying it is difficult to tell unless you understand the reason behind every single ASNs announcement choices. Granted, some ASNs have no idea themselves. But how can you tell the difference between those ones and the ones with legit reasons? Nonetheless, none of these reasons are excuses to announce useless stuff that could be aggregated beyond your ASN. We need to continue work on infinite IP space and a scalable inter-AS routing protocol to match. That way, as long as you aren't announcing any networks that aren't yours, I don't care how mangled your announcements are to me. :-) -jr ---- Josh Richards [JTR38/JR539-ARIN] <jrichard@geekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us> Geek Research LLC - <URL:http://www.geekresearch.com/> IP Network Engineering and Consulting
participants (4)
-
Danny McPherson -
James Aldridge -
Josh Richards -
Valdis.Kletnieks＠vt.edu