This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats@lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith <pfs@cisco.com>. Routing Table Report 04:00 +10GMT Sat 14 Oct, 2006 Analysis Summary ---------------- BGP routing table entries examined: 200339 Prefixes after maximum aggregation: 108814 Unique aggregates announced to Internet: 97044 Total ASes present in the Internet Routing Table: 23359 Origin-only ASes present in the Internet Routing Table: 20346 Origin ASes announcing only one prefix: 9795 Transit ASes present in the Internet Routing Table: 3013 Transit-only ASes present in the Internet Routing Table: 71 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 2 Unregistered ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 10 Number of addresses announced to Internet: 1615440908 Equivalent to 96 /8s, 73 /16s and 172 /24s Percentage of available address space announced: 43.6 Percentage of allocated address space announced: 60.3 Percentage of available address space allocated: 72.3 Total number of prefixes smaller than registry allocations: 100498 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 43873 Total APNIC prefixes after maximum aggregation: 17556 Prefixes being announced from the APNIC address blocks: 41522 Unique aggregates announced from the APNIC address blocks: 18483 APNIC Region origin ASes present in the Internet Routing Table: 2716 APNIC Region origin ASes announcing only one prefix: 762 APNIC Region transit ASes present in the Internet Routing Table: 405 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 263733600 Equivalent to 15 /8s, 184 /16s and 65 /24s Percentage of available APNIC address space announced: 82.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 100779 Total ARIN prefixes after maximum aggregation: 59537 Prefixes being announced from the ARIN address blocks: 73957 Unique aggregates announced from the ARIN address blocks: 27939 ARIN Region origin ASes present in the Internet Routing Table: 11051 ARIN Region origin ASes announcing only one prefix: 4204 ARIN Region transit ASes present in the Internet Routing Table: 1030 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 304717696 Equivalent to 18 /8s, 41 /16s and 159 /24s Percentage of available ARIN address space announced: 67.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks 24/8, 63/8, 64/5, 72/6, 76/8, 96/6, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 40787 Total RIPE prefixes after maximum aggregation: 26935 Prefixes being announced from the RIPE address blocks: 37718 Unique aggregates announced from the RIPE address blocks: 25160 RIPE Region origin ASes present in the Internet Routing Table: 8625 RIPE Region origin ASes announcing only one prefix: 4537 RIPE Region transit ASes present in the Internet Routing Table: 1399 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 267544356 Equivalent to 15 /8s, 242 /16s and 103 /24s Percentage of available RIPE address space announced: 72.5 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-41983 RIPE Address Blocks 62/8, 77/8, 78/7, 80/5, 88/6, 193/8, 194/7, 212/7 and 217/8 LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 12550 Total LACNIC prefixes after maximum aggregation: 3857 Prefixes being announced from the LACNIC address blocks: 10575 Unique aggregates announced from the LACNIC address blocks: 6257 LACNIC Region origin ASes present in the Internet Routing Table: 733 LACNIC Region origin ASes announcing only one prefix: 245 LACNIC Region transit ASes present in the Internet Routing Table: 126 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 33027072 Equivalent to 1 /8s, 247 /16s and 244 /24s Percentage of available LACNIC address space announced: 49.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 189/8, 190/8, 200/7 AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 2348 Total AfriNIC prefixes after maximum aggregation: 929 Prefixes being announced from the AfriNIC address blocks: 1660 Unique aggregates announced from the AfriNIC address blocks: 1031 AfriNIC Region origin ASes present in the Internet Routing Table: 163 AfriNIC Region origin ASes announcing only one prefix: 47 AfriNIC Region transit ASes present in the Internet Routing Table: 27 Average AfriNIC Region AS path length visible: 3.6 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 4304384 Equivalent to 0 /8s, 65 /16s and 174 /24s Percentage of available AfriNIC address space announced: 12.8 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8 APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4134 1245 8270 238 CHINANET-BACKBONE 4755 1009 255 67 Videsh Sanchar Nigam Ltd. Aut 9583 957 109 15 Sify Limited 9498 866 212 70 BHARTI BT INTERNET LTD. 4766 741 4436 307 Korea Telecom (KIX) 1221 609 1780 468 Telstra Pty Ltd 7545 542 124 74 TPG Internet Pty Ltd 17488 534 33 12 Hathway IP Over Cable Interne 17676 499 10933 63 Softbank BB Corp. 18101 462 85 20 Reliance Infocom Ltd Internet 9443 454 111 74 Primus Telecommunications 17849 430 36 126 Telecommunications Technology 9942 428 77 127 COMindico Australia 4802 413 86 150 Wantree Development 4812 411 741 63 China Telecom (Shanghai) 17974 364 129 12 PT TELEKOMUNIKASI INDONESIA 17557 363 30 177 Pakistan Telecom 2907 335 1734 312 SINET Japan 4837 324 3556 140 chinanet IDC center beijing n 10139 307 23 6 Meridian Telekoms ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7018 1523 6209 983 AT&T WorldNet Services 2386 1167 614 743 AT&T Data Communications Serv 4323 1030 784 294 Time Warner Telecom 6197 1017 608 498 BellSouth Network Solutions, 18566 967 272 8 Covad Communications 701 965 6742 783 UUNET Technologies, Inc. 721 961 21925 306 DLA Systems Automation Center 174 958 6823 884 Cogent Communications 1239 834 2763 588 Sprint 11492 754 90 13 Cable One 20115 749 673 392 Charter Communications 19262 739 2391 179 Verizon Global Networks 22773 718 1744 46 Cox Communications, Inc. 209 709 3633 557 Qwest 7011 684 210 429 Citizens Utilities 852 592 1071 388 Telus Advanced Communications 19916 565 49 54 OLM LLC 855 547 250 74 Canadian Research Network 5668 538 145 18 CenturyTel Internet Holdings, 6478 530 1280 335 AT&T Worldnet Services RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 702 544 1928 423 UUNET - Commercial IP service 24863 367 42 14 LINKdotNET AS number 3301 311 1200 295 TeliaNet Sweden 3320 300 5013 245 Deutsche Telekom AG 8220 279 455 265 COLT Telecommunications 680 251 2041 247 DFN-IP service G-WiN 6746 246 91 224 Dynamic Network Technologies, 3246 228 469 218 Song Networks 8708 222 279 209 Romania Data Systems S.A. 9116 220 134 23 Goldenlines main autonomous s 3215 214 1872 93 France Telecom Transpac 1257 212 740 168 SWIPnet Swedish IP Network 3269 204 2277 74 TELECOM ITALIA 30890 203 18 78 SC Kappa Invexim SRL 8551 200 182 27 Bezeq International 6830 198 879 43 UPC Distribution Services 5416 186 12 11 BATELCO-BH 8866 185 37 15 Bulgarian Telecommunication C 3300 174 171 95 AUCS Communications Services 786 171 1779 171 The JANET IP Service LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 633 1810 223 UniNet S.A. de C.V. 11172 387 100 91 Servicios Alestra S.A de C.V 16814 329 20 8 NSS, S.A. 22047 303 206 11 VTR PUNTO NET S.A. 11830 285 299 9 Instituto Costarricense de El 6147 263 140 23 Telefonica Del Peru 6471 255 74 30 ENTEL CHILE S.A. 14117 235 15 8 Telefonica del Sur S.A. 7303 208 92 27 Telecom Argentina Stet-France 10481 181 72 8 Prima S.A. 6503 179 168 85 AVANTEL, S.A. 21826 144 19 31 INTERCABLE 23216 144 19 46 RAMtelecom Telecomunicaciones 7910 139 9 17 ANDINET ON LINE 19169 136 9 21 Telconet 19429 136 84 40 E.T.B. 11556 132 96 4 Cable-Wireless Panama 18822 129 8 10 TELEFONICA MANQUEHUE 14522 118 18 9 SatNet S.A. 7738 115 410 20 Telecomunicacoes da Bahia S.A AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 3741 295 804 234 The Internet Solution 8452 173 60 7 TEDATA 6713 145 139 12 Itissalat Al-MAGHRIB 2018 132 297 111 Tertiary Education Network 15475 132 84 4 Nile Online 5536 122 8 17 Internet Egypt Network 24835 116 48 6 RAYA Telecom - Egypt 33783 108 6 3 EEPAD TISP TELECOM & INTERNET 2905 75 157 68 The Internetworking Company o 2561 55 6 2 Egyptian Universities Network 15706 55 12 4 Sudatel Internet Exchange Aut 12455 38 6 3 Jambonet Autonomous system 5713 36 293 32 Telkom SA Ltd 33774 34 7 21 AS Number for Telecom Algeria 8524 30 2 6 AUCEGYPT Autonomous System 23889 28 9 13 MAURITIUS TELECOM 21280 26 4 4 Swift Global Kenya Ltd.Is an 16637 24 19 23 Johnnic e-Ventures 10798 23 1 14 Standard Bank of South Africa 21491 23 17 2 UTL On-line is RF broadband I Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4134 1245 1007 CHINANET-BACKBONE 18566 967 959 Covad Communications 4755 1009 942 Videsh Sanchar Nigam Ltd. Aut 9583 957 942 Sify Limited 9498 866 796 BHARTI BT INTERNET LTD. 11492 754 741 Cable One 4323 1030 736 Time Warner Telecom 22773 718 672 Cox Communications, Inc. 721 961 655 DLA Systems Automation Center 19262 739 560 Verizon Global Networks 17488 534 522 Hathway IP Over Cable Interne 5668 538 520 CenturyTel Internet Holdings, 6197 1017 519 BellSouth Network Solutions, 19916 565 511 OLM LLC 855 547 473 Canadian Research Network 7545 542 468 TPG Internet Pty Ltd 18101 462 442 Reliance Infocom Ltd Internet 17676 499 436 Softbank BB Corp. 15270 470 435 PaeTec.net -a division of Pae 4766 741 434 Korea Telecom (KIX) List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65534 PRIVATE 193.138.171.0/24 34238 SC OMNITECH NET SRL 24409 UNALLOCATED 203.119.29.0/24 9808 Guangdong Mobile Com Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 198.18.0.0/15 8895 KACST/ISU Riyadh Autonomous S Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 132.0.0.0/10 721 DLA Systems Automation Center 137.0.0.0/13 721 DLA Systems Automation Center 158.0.0.0/13 721 DLA Systems Automation Center 172.33.1.0/24 7018 AT&T WorldNet Services 192.44.0.0/24 5501 Fraunhofer Gesellschaft 192.44.0.0/19 702 UUNET - Commercial IP service 192.70.164.0/24 25689 National Research Council of 192.84.205.0/24 719 LANLINK autonomous system 192.172.0.0/19 721 DLA Systems Automation Center 192.249.0.0/20 3450 University of Tennessee, Knox Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:13 /11:29 /12:106 /13:214 /14:386 /15:774 /16:9045 /17:3503 /18:5721 /19:12380 /20:14008 /21:12350 /22:15648 /23:17065 /24:107765 /25:459 /26:406 /27:195 /28:70 /29:43 /30:94 /31:0 /32:37 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 950 967 Covad Communications 2386 884 1167 AT&T Data Communications Serv 7018 806 1523 AT&T WorldNet Services 6197 800 1017 BellSouth Network Solutions, 9583 788 957 Sify Limited 11492 742 754 Cable One 7011 591 684 Citizens Utilities 19916 559 565 OLM LLC 4766 550 741 Korea Telecom (KIX) 9498 517 866 BHARTI BT INTERNET LTD. 4755 439 1009 Videsh Sanchar Nigam Ltd. Aut 15270 439 470 PaeTec.net -a division of Pae 855 427 547 Canadian Research Network 5668 420 538 CenturyTel Internet Holdings, 17849 416 430 Telecommunications Technology 1239 408 834 Sprint 18101 396 462 Reliance Infocom Ltd Internet 22773 377 718 Cox Communications, Inc. 33588 371 392 Bresnan Communications, LLC. 17488 354 534 Hathway IP Over Cable Interne Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 6:1 8:54 12:1643 13:1 15:16 16:3 17:3 18:4 20:41 24:819 25:1 32:57 38:258 40:57 41:22 44:3 47:7 52:4 53:1 55:1 56:3 57:25 58:224 59:289 60:220 61:899 62:1046 63:1904 64:3136 65:2236 66:3032 67:646 68:648 69:1655 70:405 71:92 72:960 74:88 75:9 80:831 81:701 82:631 83:398 84:399 85:688 86:412 87:459 88:235 89:513 91:27 121:55 122:18 124:418 125:649 128:281 129:227 130:123 131:313 132:35 133:9 134:166 135:50 136:177 137:106 138:184 139:47 140:528 141:130 142:343 143:193 144:239 145:43 146:319 147:137 148:362 149:177 150:115 151:121 152:76 153:121 154:5 155:255 156:160 157:167 158:155 159:171 160:97 161:84 162:216 163:161 164:226 165:218 166:239 167:250 168:487 169:128 170:384 171:11 172:1 189:2 190:239 192:5761 193:3518 194:2737 195:2098 196:911 198:3891 199:3312 200:4490 201:969 202:6946 203:7146 204:3925 205:2125 206:2428 207:2960 208:2291 209:3507 210:2189 211:845 212:1343 213:1506 214:377 215:39 216:4058 217:1146 218:344 219:258 220:796 221:383 222:233 End of report Report Website: http://thyme.apnic.net
On Oct 13, 2006, at 2:02 PM, Routing Analysis Role Account wrote:
Routing Table Report 04:00 +10GMT Sat 14 Oct, 2006
Analysis Summary ----------------
BGP routing table entries examined: 200339 Prefixes after maximum aggregation: 108814
Shall we all have a moment of silence for 200K prefixes in the global table. Maybe reboot all our routers at once or something? -- TTFN, patrick
I'm buying more stock in ram producers!!!! -- Neil J. McRae -- Alive and Kicking neil@DOMINO.ORG - Sent from my Blackberry Wireless -----Original Message----- From: "Patrick W. Gilmore" <patrick@ianai.net> Date: Fri, 13 Oct 2006 14:16:12 To:nanog@nanog.org Cc:"Patrick W. Gilmore" <patrick@ianai.net> Subject: 200K prefixes - Weekly Routing Table Report On Oct 13, 2006, at 2:02 PM, Routing Analysis Role Account wrote:
Routing Table Report 04:00 +10GMT Sat 14 Oct, 2006
Analysis Summary ----------------
BGP routing table entries examined: 200339 Prefixes after maximum aggregation: 108814
Shall we all have a moment of silence for 200K prefixes in the global table. Maybe reboot all our routers at once or something? -- TTFN, patrick
On Thu, 12 Oct 2006 00:02:32 -0000, =?UTF-8?B?TmVpbCBKLiBNY1JhZQ==?= said:
I'm buying more stock in ram producers!!!!
How many routers carry a full routing table? Let's say 100K of them, and you can sell 128M more memory for each one. Now how many boxes is Dell going to sell with 1G and 2G of RAM so Vista runs? I suspect consumers sales in Topeka, Kansas alone will sell more RAM than the worldwide market for routers that do full routing tables. Let's keep some perspective here. :)
I think you have seriouisly under estimated that. think of the routers with distributed line cards then all the boxes that are soon to be a trash can job because they can't be upgraded. We deployed a load of prp2 cards and decided to max the ram out as the aggrevation of a mid production upgrade when we hit 300k isn't worth not doing it. Cheers Neil -- Neil J. McRae -- Alive and Kicking neil@DOMINO.ORG - Sent from my Blackberry Wireless -----Original Message----- From: Valdis.Kletnieks@vt.edu Date: Fri, 13 Oct 2006 15:35:20 To:neil@domino.org Cc:"Patrick W. Gilmore" <patrick@ianai.net>, owner-nanog@merit.edu,nanog@nanog.org Subject: Re: 200K prefixes - Weekly Routing Table Report On Thu, 12 Oct 2006 00:02:32 -0000, =?UTF-8?B?TmVpbCBKLiBNY1JhZQ==?= said:
I'm buying more stock in ram producers!!!!
How many routers carry a full routing table? Let's say 100K of them, and you can sell 128M more memory for each one. Now how many boxes is Dell going to sell with 1G and 2G of RAM so Vista runs? I suspect consumers sales in Topeka, Kansas alone will sell more RAM than the worldwide market for routers that do full routing tables. Let's keep some perspective here. :)
On Thu, 12 Oct 2006 00:53:37 -0000, Neil J. McRae said:
I think you have seriouisly under estimated that. think of the routers with distributed line cards then all the boxes that are soon to be a trash can job because they can't be upgraded.
Hmm. <looks around AS1312> 2 /16s, I'll be *generous* and say 100 interfaces that have full routing tables (it's actually probably closer to a dozen). But I have *at least* 30K user machines on my network that will all either be stuck on XP or buying a gigabyte or two each for Vista. Even if my 100K is off by a factor of 5 or even 10, that's still just a *pimple* on the RAM sales that will happen even if Vista *flops*.
On Thu, 12 Oct 2006, [UTF-8] Neil J. McRae wrote:
I'm buying more stock in ram producers!!!!
RAM's cheap. Buy stock in cisco and/or juniper. forklift router upgrades are not so cheap. A whole lot of NPE/RSP/SUP boards will be unsuitable for core router use (without route filtering) in the next year or two. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Sorry, I got several questions emailed to me, so I'll save my own bandwidth at the expense of everyone else's, and hopefully answer some people that didn't take the time/effort to ask... The Dirty-Thirty is what I called the list of "Aggregation Summery" in the cidr report (cidr-report.org) that gets posted to the NANOG list. They put the top 30 ASes that have the most to gain through aggregation in their report for all to see. When discussing this in the past I referred to it as the dirty thirty. In the past, I suggested giving out "I'm the dirty thirty" t-shirts at NANOG meetings to those attending from the networks listed. Require them to be worn to attend. Put slogans on them like "Aggregate is what you put in concrete, right?" Have a cute picture of a stick person on it with a concrete block for a head, next to a router or something. More affective, less funny, and also somewhat discussed in the past, was my suggestion of the creation of a route-server style of distribution of filters (like the cymru bogon servers) that would filter routes to the top 5 people on the list, essentially black holing the absolute worst of the worst. It basically would be similar to email RBL, except that it would break the entire net, not just SMTP. ;-) While it may be sacrilegious to discuss such things like purposely breaking parts of the net on the NANOG list, it's for the greater good. So hear me now, and belive me later......... It would work like this: Step 1) Read the cidr report 2)Contact those top 5 networks with a simple message. "Congratulations! You're in the top 5 of the dirty thirty! Aggregate now, because if you're still on the dirty-thirty list 60 days from now, and your entry can gain more than a 30% reduction size through aggregation, we're going to add you do the black hole server. Have a nice day." 3)Do this weekly. 3a)Shrug off threats of lawsuits. 4)In the mean time, a few crazy network operators would actually subscribe to the "Aggregation Route Server." It might be a guy with an ASN and a /24 in his apartment, or a small company with an underpowered router that's facing an upgrade and wants to try to change the world, maybe a small host or ISP, or whatever. Or maybe a larger organization might actually be insane enough to apply this to all of their border routers. "Crazy" is the key operator here. And I mean that in a good way. :-) It's crazy that the net even works... just announce some routes, and the world accepts them? Now *THAT'S* crazy! The whole idea is a terror tactic like weapons of mass destruction and mine fields. And email RBLs. Remember when some through RBLs to be crazy? Who would block email and cause collateral damage for themselves just to stop a few spams? Turned out that the answer to that question was "Everybody." Getting blacklisted had quite an affect on people, and that alone closed a lot of open relays. Being responsible, and working to fight spam wasn't enough. It took a terror weapon like RBLs to get people to close their relays. I maintain that we are at the same point with the routing table. It would provide motivation to aggregate,to stay as far away from that top 30 list as possible. And because the rest of the world wouldn't actually know WHO is subscribed, or what impact it might actually have, or if say, a large tier-1 nsp might actually subscribe to it just to be belligerent (tired of needing more RAM for their core routers, and can make a crazy business case for it [didn't Sprint do something like that a long time ago or something?] ) or actually just plan crazy. Maybe no one would join. That's OK too. The dirty thirty participants don't get to know that information. No one would know except for the operators of the (free) service. Because while you may have to be crazy to subscribe to it, you'd have to be equally crazy to sit on the top of the dirty thirty, and ignore the warnings that you might be black holed. Maybe a single tier-1 nsp decides to use it. That's pretty significant. Fight crazy with more crazy! 5)After 60 days, if the network that was in the top 5 to qualify hasn't moved out of the dirty thirty all together, actually go add all their un-aggregated space to the route server. Because we only really want to block the more specifics that are causing the bloat.... 5a)Continuously monitor the actually global routing table, in somewhat real time... when they get aggregated, stop the madness immediately, and automagically. 6)Avoid lawsuits. Or get sued. Or fold and comply with the lawyers' demands. Whatever. (I don't have a solution to this.... it's just a general requirement... I didn't say this would be easy, or even possible to operate in a sustainable manor.... I'm just saying that it is technically possible. Logic would dictate that RBL operators *shouldn't* be liable to lawsuits from spammers, but this is a pretty messed up world....) 7)Check to see if there routing suddenly becomes more aggregated. At some point, of the table as aggregated enough, it's not worth continuing. The point is maximize gains (go after the worst offenders, and scare everyone else in to being responsible too) with minimal effort. It's not possible to max aggregate everything, and that's not the point. The point is to get the worst of the worst to be more responsible. Unfortunately, experience has taught me that there will always be plenty of irresponsible and/or clueless people to go around. So it very well may be a never ending process. 8)Return to step 1. I've got some old routers sitting around, and a network to host them on..... I've wanted to do this now for quite some time, but don't have the time resources to make it all work. Anyone game to help me out with this? It's just crazy enough to work. Or am *I* just crazy for thinking so? ---------------------------------- "I'll reboot mine, if you reboot yours."
Patrick W. Gilmore said the following on 14/10/06 04:16:
On Oct 13, 2006, at 2:02 PM, Routing Analysis Role Account wrote:
BGP routing table entries examined: 200339 Prefixes after maximum aggregation: 108814
Shall we all have a moment of silence for 200K prefixes in the global table.
My view actually hit 200k on Wednesday morning, then dipped back under by a few hundred on Thursday. I was kinda hoping that it would hit 200K on Tuesday, then I could have added the announcement to my aggregation recommendations lightning talk! ;-) Bit sad that a 200K table can be aggregated down to 109k prefixes with no loss of path information (in my BGP table view).
Maybe reboot all our routers at once or something?
Who wants to go first...? Then again, maybe better not... philip --
On Oct 13, 2006, at 3:04 PM, Philip Smith wrote:
I was kinda hoping that it would hit 200K on Tuesday, then I could have added the announcement to my aggregation recommendations lightning talk! ;-) Bit sad that a 200K table can be aggregated down to 109k prefixes with no loss of path information (in my BGP table view).
I find this interesting. Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info? If there were a way to guarantee certain prefixes are completely superfluous, we could make a hit list of just those providers, then ridicule or filter or cause them pain in some way to make them stop causing us pain. I haven't seen that type of report posted publicly, just "this CIDR can fit in that one" without actual guarantees that _paths_ are equivalent. (Usually the origin AS is matched as well as the prefixes, but that's not the same as guaranteeing the path is equivalent.) Of course, this is non-trivial. But then neither is aggregating the global table. :) -- TTFN, patrick
On Fri, Oct 13, 2006 at 03:14:38PM -0400, Patrick W. Gilmore wrote:
On Oct 13, 2006, at 3:04 PM, Philip Smith wrote:
I was kinda hoping that it would hit 200K on Tuesday, then I could have added the announcement to my aggregation recommendations lightning talk! ;-) Bit sad that a 200K table can be aggregated down to 109k prefixes with no loss of path information (in my BGP table view).
I find this interesting.
Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info?
If there were a way to guarantee certain prefixes are completely superfluous, we could make a hit list of just those providers, then ridicule or filter or cause them pain in some way to make them stop causing us pain. I haven't seen that type of report posted publicly, just "this CIDR can fit in that one" without actual guarantees that _paths_ are equivalent. (Usually the origin AS is matched as well as the prefixes, but that's not the same as guaranteeing the path is equivalent.)
Of course, this is non-trivial. But then neither is aggregating the global table. :)
how much of this could be mitigated if people properly announced aggregates and used a provider-local no-export to balance their links with them? it does make those policies more complicated than the simple cut+paste examples that they've likely used in the past, but could possibly allow the "traffic-eng" with their upstream without the global pollution. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Oct 13, 2006, at 3:26 PM, Jared Mauch wrote:
On Fri, Oct 13, 2006 at 03:14:38PM -0400, Patrick W. Gilmore wrote:
Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info?
If there were a way to guarantee certain prefixes are completely superfluous, we could make a hit list of just those providers, then ridicule or filter or cause them pain in some way to make them stop causing us pain. I haven't seen that type of report posted publicly, just "this CIDR can fit in that one" without actual guarantees that _paths_ are equivalent. (Usually the origin AS is matched as well as the prefixes, but that's not the same as guaranteeing the path is equivalent.)
Of course, this is non-trivial. But then neither is aggregating the global table. :)
how much of this could be mitigated if people properly announced aggregates and used a provider-local no-export to balance their links with them? it does make those policies more complicated than the simple cut+paste examples that they've likely used in the past, but could possibly allow the "traffic-eng" with their upstream without the global pollution.
Sorry if I wasn't clear before, but I consider path info _just for your first hop upstream_ superfluous for the rest of the Internet. Does anyone think this is an unreasonable restriction? More important question: How many people are doing TE or something and not applying no-export when they could? If you need help fixing that, or even figuring out if you need to fix it, I guarantee you several people on this list would help you, many for free. This is one of the reasons things become "non-trivial". How do you prove that a disgregate prefix is useless to anyone except that one network? I do not think it is impossible. But it certain ain't easy. -- TTFN, patrick
patrick@ianai.net ("Patrick W. Gilmore") writes:
Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info?
before we could be sure that an aggregation proposal was nondestructive, we'd have to model it from where a lot of people sit, not just patrick. on the one hand this seems to be a useful endeavour. in addition to measuring the total number of routes, we probably ought to measure the number of non-TE-related routes, and focus our attention on those routes and also the ratio ("global TE cost borne by the routing system.") on the other hand i dispair of finding a set of observation posts and metrics that will abstract TE out of the observed routes in a way that wouldn't be seen as controversial or useless by most of the community. -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DHCP. Email training@isc.org. -- Paul Vixie
On Oct 14, 2006, at 11:09 AM, Paul Vixie wrote:
patrick@ianai.net ("Patrick W. Gilmore") writes:
Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info?
before we could be sure that an aggregation proposal was nondestructive, we'd have to model it from where a lot of people sit, not just patrick.
I do believe that was the point of my second & third sentence.
on the one hand this seems to be a useful endeavour. in addition to measuring the total number of routes, we probably ought to measure the number of non-TE-related routes, and focus our attention on those routes and also the ratio ("global TE cost borne by the routing system.")
I'm not sure you could separate "TE routes" from "$FOO routes" externally. Unless you classify everything that doesn't go the way - you- think it should go as "TE". (Possibly a valid assumption.)
on the other hand i dispair of finding a set of observation posts and metrics that will abstract TE out of the observed routes in a way that wouldn't be seen as controversial or useless by most of the community.
Since we are discussing putting pressure on people who do stupid thing, not shooting them in the head, we do not need to be 100% accurate. A list of provider who most likely are filling the table, and then allowing people to filter, prod, annoy, e-mail, call, etc., those providers is enough. Right now we just have "these people could -theoretically- aggregate", without actually knowing if path info is lost. -- TTFN, patrick
On Oct 13, 2006, at 2:02 PM, Routing Analysis Role Account wrote:
Routing Table Report 04:00 +10GMT Sat 14 Oct, 2006
Analysis Summary ----------------
BGP routing table entries examined: 200339 Prefixes after maximum aggregation: 108814
Shall we all have a moment of silence for 200K prefixes in the global table.
Maybe reboot all our routers at once or something?
-- TTFN, patrick
Thanks for reminding me to change my neighbor maximum-prefix 250000 80 statements to something more "reasonable" before I started getting warnings to my pager! I'm still a few thousand routes shy of 200K as of today...... I like that second line that you included. Maximum aggregation isn't always possible, but I think there are a lot of operators out there that don't aggregate as much as they could. They cite various reasons for chewing up router memory ( "Oh, it's technically impossible....". or my favorite.... "because someone could announce more specifics and steal our traffic, so we have to announce 842 /24s all separately, ALL THE TIME" ) while the rest of the net doesn't seem to have those issues, (or they deal with them as they happen... "uh, oh, someone's blackholing our traffic, let's announce our space as /24s until we can get that other operator to correct their stupidity... we'll withdraw the /24s as soon as it's fixed 22 hours later....") You should have put a difference number there too, just so everyone didn't have to get out their calculators to figure out how many extra routes there are (91525). So since my calculator is out, I did some more numbers. Of those 91,525 routes that are extra routes in the table, 14,444 of those are the dirty-30. So of those top 30 ASes that I refer to as the "Dirty Thirty", represent .13% (POINT ONE THREE PERCENT!) of the ASes, but they contribute 15.7% of the amount of route-bloat on the net!! .13%,=15.7%. The dirty-thirty is a shameful list. But apparently there isn't enough pressure from within the routing community to not be on it. At least not yet. ;-) ---------------------------------- "I'll reboot mine, if you reboot yours."
participants (9)
-
Jared Mauch -
Jerry Pasker -
Jon Lewis -
Neil J. McRae -
Patrick W. Gilmore -
Paul Vixie -
Philip Smith -
Routing Analysis Role Account -
Valdis.Kletnieks＠vt.edu