BGP Update Report
BGP Update Report Interval: 29-Sep-06 -to- 12-Oct-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS17974 23479 2.7% 65.4 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 2 - AS17885 13106 1.5% 170.2 -- JKTXLNET-AS-AP PT Excelcomindo Pratama 3 - AS855 7915 0.9% 13.9 -- CANET-ASN-4 - Aliant Telecom 4 - AS4795 7874 0.9% 35.2 -- INDOSAT2-ID INDOSATNET-ASN 5 - AS287517802 0.9% 69.7 -- CAUCASUS-NET-AS Caucasus Network Tbilisi, Georgia 6 - AS8390 6758 0.8% 99.4 -- TPN-AS Telecom Partners Network Ltd. 7 - AS702 6304 0.7% 8.8 -- AS702 MCI EMEA - Commercial IP service provider in Europe 8 - AS252335955 0.7% 26.5 -- AWALNET-ASN Autonomus System number for Awalnet 9 - AS701 5728 0.7% 6.0 -- ALTERNET-AS - UUNET Technologies, Inc. 10 - AS4621 5533 0.6% 41.6 -- UNSPECIFIED UNINET-TH 11 - AS4323 5186 0.6% 5.0 -- TWTC - Time Warner Telecom, Inc. 12 - AS4787 5168 0.6% 28.1 -- ASN-CBN ASN CBNnet 13 - AS308904921 0.6% 24.1 -- EVOLVA Evolva Telecom 14 - AS124974806 0.6% 96.1 -- SANET-GE SANET NETWORK (AS) 15 - AS346954754 0.6% 89.7 -- E4A-AS E4A Primary AS 16 - AS191694557 0.5% 33.8 -- Telconet S.A 17 - AS9425 4531 0.5% 67.6 -- CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc 18 - AS9121 4450 0.5% 39.0 -- TTNET TTnet Autonomous System 19 - AS125644363 0.5% 155.8 -- CMBG-AS Bulgarian Government Autonomous System 20 - AS239184315 0.5% 34.8 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS3043 2078 0.2%2078.0 -- AMPHIB-AS - Amphibian Media Corporation 2 - AS392502120 0.2%1060.0 -- COLOPROVIDER-AS Colo Provider 3 - AS34378 727 0.1% 727.0 -- RUG-AS Razguliay-UKRROS Group 4 - AS3944 688 0.1% 688.0 -- PARTAN-LAB - Partan Partan 5 - AS12922 589 0.1% 589.0 -- MULTITRADE-AS Bank Outsourcer 6 - AS185602242 0.3% 560.5 -- CYBERSHORE - Cybershore, Inc 7 - AS36877 870 0.1% 435.0 -- MWEB_AFRICA-NAMIBIA 8 - AS1525 353 0.0% 353.0 -- 9 - AS33188 705 0.1% 352.5 -- SCS-NETWORK-1 - Sono Corporate Suites 10 - AS5535 677 0.1% 338.5 -- FAO ORG 11 - AS31942 648 0.1% 324.0 -- COBECV - COBE CV 12 - AS31440 320 0.0% 320.0 -- DSK-AS DSK Bank 13 - AS29544 295 0.0% 295.0 -- MAURITEL-AS Mauritanian Telecommunication Company 14 - AS15743 283 0.0% 283.0 -- IPH IPH AS 15 - AS141122256 0.3% 282.0 -- NET-SECURENET-MTL - SecureNet Information Services Inc. 16 - AS18040 268 0.0% 268.0 -- MBTNET Mobitai ISP Network Information Center 17 - AS12408 249 0.0% 249.0 -- BIKENT-AS Bikent Ltd. Autonomous system 18 - AS25250 247 0.0% 247.0 -- GAMTEL-AS Gambia Telecoms Backbone Network Network 19 - AS181591420 0.2% 236.7 -- GONOPHONE-AS-BD Gonophone Bangladesh Ltd 20 - AS39298 235 0.0% 235.0 -- SERI Seri Bilgi Teknolojileri ve Destek Hizmetleri TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.199.128.0/19 2422 0.2% AS4755 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 2 - 209.140.24.0/242078 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 3 - 83.98.220.0/23 1268 0.1% AS39250 -- COLOPROVIDER-AS Colo Provider 4 - 143.81.0.0/21 1021 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 5 - 74.243.80.0/20 951 0.1% AS6389 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 6 - 83.98.163.0/24 852 0.1% AS39250 -- COLOPROVIDER-AS Colo Provider 7 - 193.242.123.0/24727 0.1% AS34378 -- RUG-AS Razguliay-UKRROS Group 8 - 198.32.7.0/24 688 0.1% AS3944 -- PARTAN-LAB - Partan Partan 9 - 212.103.162.0/24635 0.1% AS8452 -- TEDATA TEDATA 10 - 194.105.61.0/24 589 0.1% AS12922 -- MULTITRADE-AS Bank Outsourcer 11 - 88.213.145.0/24 585 0.1% AS34695 -- E4A-AS E4A Primary AS 12 - 208.46.135.0/24 567 0.1% AS18560 -- CYBERSHORE - Cybershore, Inc 13 - 63.237.136.0/24 565 0.1% AS18560 -- CYBERSHORE - Cybershore, Inc 14 - 65.242.131.0/24 563 0.1% AS18560 -- CYBERSHORE - Cybershore, Inc 15 - 63.112.156.0/22 547 0.1% AS18560 -- CYBERSHORE - Cybershore, Inc 16 - 205.97.32.0/20 533 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 17 - 84.205.65.0/24 532 0.1%
The Cidr Report
This report has been generated at Fri Oct 13 21:48:55 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
06-10-06196932 128148
07-10-06197203 128093
08-10-06197189 128126
09-10-06197170 128097
10-10-06197344 128097
11-10-06197372 128097
12-10-06197372 128515
13-10-06197518 128377
AS Summary
23271 Number of ASes in routing system
9792 Number of ASes announcing only one prefix
1486 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91322880 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 13Oct06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 197694 1284146928035.0% All ASes
AS4134 1220 273 94777.6% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4755 999 65 93493.5% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS18566 967 127 84086.9% COVAD - Covad Communications
Co.
AS4323 1026 297 72971.1% TWTC - Time Warner Telecom,
Inc.
AS9498 867 146 72183.2% BBIL-AP BHARTI BT INTERNET
LTD.
AS22773 715 52 66392.7% CCINET-2 - Cox Communications
Inc.
AS721960 307 65368.0% DISA-ASNBLK - DoD Network
Information Center
AS6197 1018 492 52651.7% BATI-ATL - BellSouth Network
Solutions, Inc
AS19262 694 179 51574.2% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS7018 1486 984 50233.8% ATT-INTERNET4 - ATT WorldNet
Services
AS19916 565 68 49788.0% ASTRUM-0001 - OLM LLC
AS17488 534 43 49191.9% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS11492 756 295 46161.0% CABLEONE - CABLE ONE
AS855547 88 45983.9% CANET-ASN-4 - Aliant Telecom
AS18101 462 25 43794.6% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS17676 499 63 43687.4% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS2386 1166 745 42136.1% INS-AS - ATT Data
Communications Services
AS3602 524 103 42180.3% AS3602-RTI - Rogers Telecom
Inc.
AS4766 706 311 39555.9% KIXS-AS-KR Korea Telecom
AS812420 33 38792.1% ROGERS-CABLE - Rogers Cable
Inc.
AS15270 466 104 36277.7% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS4812 411 63 34884.7% CHINANET-SH-AP China Telecom
(Group)
AS6467 381 61 32084.0% ESPIRECOMM - Xspedius
Communications Co.
AS16852 372 54 31885.5% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS16814 329 42 28787.2% NSS S.A.
AS33588 392 105 28773.2% BRESNAN-AS - Bresnan
Communications, LLC.
AS9583 959 683 27628.8% SIFY-AS-IN Sify Limited
AS24863 366 92 27474.9% LINKDOTNET-AS LINKdotNET AS
number
AS14654 300 30 27090.0% WAYPORT - Wayport
AS17849 429 162 26762.2% GINAMHANVIT-AS-KR hanvit ginam
ISOI II - a DA Workshop (announcement and CFP)
[Apologies to those who receive this message multiple times] The second Internet Security Operations and Intelligence (ISOI) DA workshop will take place on the 25th and 26th of January, 2007. It will be hosted by the Microsoft Corporation, in Redmond WA. An after-party dinner will be hosted by Trendmicro. This workshop's main topic is BotMaster Operational Tactics - the use of vulnerabilities and 0day exploits in the wild. (by spyware, phishing and botnets for their businesses). Secondary subjects include DDoS, phishing and general botnet subjects. The workshop's purpose is to bring together members of the Internet security operations community at large and DA and MWP specifically, and share information, as well as plan our future operations. It is open only to the following vetted communities: DA, MWP (and sister communities such as routesec), OARC, NSP-SEC, FIRST. MAAWG, anti virus vetted groups and the honey net project. Among the attendees are: Professionals from Internet Service Providers (ISPs), Anti Virus vendors, Anti Spam vendors and projects, CERT teams, Law Enforcement, Academia, etc. coming together to work on the most recent technology, intelligence and operations being done online today for the security of the Internet. No reporters are allowed. CFP: The call for papers is now open to the public. The main subject of interest is vulnerabilities and 0day exploits used in the wild. Secondary subjects are DDoS, phishing and general botnet subjects. Submission is simple, email us directly with your topic and some data to back it up by December 10th, to [EMAIL PROTECTED] For more information please visit: http://isotf.org/isoi2.html For the agenda of our previous workshop hosted by Cisco Systems, Inc., please visit: http://isotf.org/isoi.html Gadi Evron, ISOI/DA coordinator and organizer.
The Postel Network Operator's Scholarship
The Internet Society (ISOC) a 501c(3) corporation (http:// www.isoc.org/isoc/general/trustees/incorp.shtml), has agreed to accept a restricted donation from an anonymous source to be known as the Postel Network Operator's Scholarship. The Scholarship will be awarded annually to a recipient selected by a Selection Committee consisting of a representative of the then serving Board of ARIN (The American Registry of Internet Numbers - http://www.arin.net) and a representative of the then serving Steering Committee of NANOG (The North American Network Operator's Group - http://www.nanog.org). The award is intended to enable a deserving network operator who would not otherwise be able to attend the Joint Meeting to do so, and whose attendance at the Joint Meeting will continue to build on the legacy of Jon's lifetime contribution to the Internet. The Selection Committee will develop an open and public application process, and will whimsically select the annual recipient exclusively in response to the question: What Would Jon Do? if he were asked to select a recipient. There are no criteria or restrictions or other requirements, including but not limited to nationality, location, age, or gender. The scholarship will cover the costs of travel from the recipient's home city to the Joint Meeting. It will also cover the costs of Hotel accommodation at the Conference Hotel. It will include a daily stipend for food, beverages, and incidentals. It is expected that the attendence fee for the meetings will be waived by ARIN and NANOG. The membership of the Selection Committee shall not be changed except in the event that the membership of either the Board (in the case of ARIN) or the Steering Committee (in the case of NANOG) ceases to be based on the popular vote of the community each serve; in which case the member whose process changes will be replaced by a similar body that is based on the popular vote of the community that was served by the ineligible member, and which will be appointed at the sole discretion of the Board of Trustees of the Internet Society, and under the same terms as the initial Selection Committee. At its option, the Internet Society may increase or decrease the number of recipients each year based on the current state of the Scholarship Fund, and the variable costs of travel and accommodation.
Weekly Routing Table Report
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 [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. 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 Blocks4608-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 Blocks24/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
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
Glass / Metro connectivity in Denver?
Does anyone have a list of providers(besides L3 and Q) that are available in the Denver metro area with gig/10gig transport/waves/dark capacity? Please respond off-list. I can summarize and forward to those interested, just let me know. Thanks in advance, Greg S.
Re: 200K prefixes - Weekly Routing Table Report
Somehow it seems appropriate for today: Friday the 13th. :-) - ferg -- Patrick W. Gilmore [EMAIL PROTECTED] wrote: 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 -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: 200K prefixes - Weekly Routing Table Report
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 --
Aggregation path information [was: 200K prefixes - Weekly Routing Table Report]
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
Re: 200K prefixes - Weekly Routing Table Report
I'm buying more stock in ram producers -- Neil J. McRae -- Alive and Kicking [EMAIL PROTECTED] - Sent from my Blackberry Wireless -Original Message- From: Patrick W. Gilmore [EMAIL PROTECTED] Date: Fri, 13 Oct 2006 14:16:12 To:[EMAIL PROTECTED] Cc:Patrick W. Gilmore [EMAIL PROTECTED] 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
Call for Volunteers for Mailing List Administration Panel
The NANOG charter, as amended by the community as part of the voting process in St Louis, requires the reappointment of members of the Mailing List Administration Panel at the autumn meeting. Correspondingly, there are now openings on the panel. According to the charter: ... The NANOG list will be administered and minimally moderated by a panel selected by the Steering Committee. Accordingly, the Steering Committee is soliciting nominations for the Mailing List Admininistration Panel, from now through 1700 UTC, Thursday 19 October 2006. ** Procedure ** To volunteer yourself or nominate someone else, please send mail to [EMAIL PROTECTED] with the following information, no later than 1700 UTC, Thursday 19 October 2006. - Your name - Nominee's name (if not you) - Nominee's email address - Nominee's phone number - Nominee's employer - Reasons why you believe the nominee is qualified to serve on the Mail List Panel. We will contact each of the nominees to verify interest and possibly request additional information. Once all nominations have been received, the Steering Committee, in cooperation with the Mailing List Admin Panel, will select the Panel. The result will be announced on the nanog-announce mailing list. ** Eligibility ** A nominee may not be a member of the NANOG Program Committee or of the NANOG Steering Committee. Anybody else actively reading the [EMAIL PROTECTED] mailing list is eligible. ** Duties ** Basic duties include reading the mailing list and assisting with keeping things on-topic. The team also deals with abuse issues as they arise. ** Length of term ** The current NANOG charter specifies term lengths of two years. If you have any questions, please post to [EMAIL PROTECTED], or email [EMAIL PROTECTED] and [EMAIL PROTECTED] Finally, on behalf of the Mailing List Panel and the Steering Committee, we would like to thank everyone for their help in making NANOG a useful environment for operators. Joe Abley, SC chair Chris Malayter, MLC chair
Re: Aggregation path information [was: 200K prefixes - Weekly Routing Table Report]
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 [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Aggregation path information [was: 200K prefixes - Weekly Routing Table Report]
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
Re: 200K prefixes - Weekly Routing Table Report
On Thu, 12 Oct 2006 00:02:32 -, =?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. :) pgplgXeuYQZPu.pgp Description: PGP signature
Re: 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 Thanks for reminding me to change my neighbor maximum-prefix 25 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.
Drone Armies CC Report - 13 Oct 2006
This is a periodic public report from the ISOTF's affiliated group 'DA' (Drone Armies (botnets) research and mitigation mailing list / TISF DA) with the ISOTF affiliated ASreport project (TISF / RatOut). For this report it should be noted that we base our analysis on the data we have accumulated from various sources, which may be incomplete. Any responsible party that wishes to receive reports of botnet command and control servers on their network(s) regularly and directly, feel free to contact us. For purposes of this report we use the following terms openthe host completed the TCP handshake closed No activity detected reset issued a RST This month's survey is of 5387 unique, domains (or IPs) with port suspect CCs. This list is extracted from the BBL which has a historical base of 13113 reported CCs. Of the suspect CCs surveyed, 872 reported as Open, 1841 reported as closed, and 862 issued resets to the survey instrument. Of the CCs listed by domain name in the our CC database, 4943 are mitigated. Top 20 ASNes by Total suspect domains mapping to a host in the ASN. These numbers are determined by counting the number of domains which resolve to a host in the ASN. We do not remove duplicates and some of the ASNs reported have many domains mapping to a single IP. Note the Percent_resolved figure is calculated using only the Total and Open counts and does not represent a mitigation effectiveness metric. Percent_ ASN Responsible Party Total OpenResolved 19318 NJIIX-AS-1 - NEW JERSEY INTERN123 20 84 13301 UNITEDCOLO-AS Autonomous System of115 41 64 4766 KIXS-AS-KR 65 22 66 30058 FDCSE FDCservers.net LLC 64 21 67 16265 LEASEWEB AS58 40 31 23522 CIT-FOONET 49 29 41 174 Cogent Communications 40 30 25 12832 Lycos Europe 40 6 85 8560 SCHLUND-AS 37 18 51 15083 IIS-129 Infolink Information Servic37 2 95 7132 SBC Internet Services 36 7 81 3269 TELECOM ITALIA 32 9 72 9318 HANARO-AS 31 6 81 33597 InfoRelay Online Systems, Inc. 29 0100 25761 STAMIN-2 Staminus Communications 29 15 48 4134 CHINANET-BACKBONE 29 3 90 13749 EVRY Everyones Internet28 2 93 8972 INTERGENIA-ASN intergenia autonomou28 4 86 3786 ERX-DACOMNET 27 10 63 13213 UK2NET-AS UK-2 Ltd Autonomous Syste26 3 88 Top 20 ASNes by number of active suspect CCs. These counts are determined by the number of suspect domains or IPs located within the ASN completed a connection request. Percent_ ASN Responsible Party Total OpenResolved 13301 UNITEDCOLO-AS Autonomous System of115 41 64 16265 LEASEWEB AS58 40 31 174 Cogent Communications 40 30 25 23522 CIT-FOONET 49 29 41 30407 Velcom.com 25 24 4 4766 KIXS-AS-KR 65 22 66 30058 FDCSE FDCservers.net LLC 64 21 67 19318 NJIIX-AS-1 - NEW JERSEY INTERN123 20 84 8560 SCHLUND-AS 37 18 51 19166 Alpha Red, INC 20 17 15 9121 TTNet 24 17 29 25761 STAMIN-2 Staminus Communications 29 15 48 3786 ERX-DACOMNET 27 10 63 3269 TELECOM ITALIA 32 9 72 28753 NETDIRECT AS NETDIRECT Frankfurt 16 9 44 7479 KDDHK-AS-AP KDD HONG KONG LIMITED 9 9 0 18942 WEBHO-3 WebHostPlus Inc13 9 31 6140 ImpSat 9 8 11 7132 SBC Internet Services 36 7 81 9911 CONNECTPLUS-AP Singapore Telecom9 7 22 Randal Vaughn Gadi Evron Professor ge at linuxbox.org Baylor University Waco, TX (254) 710 4756 randy_vaughn at baylor.edu
Re: 200K prefixes - Weekly Routing Table Report
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 [EMAIL PROTECTED] - Sent from my Blackberry Wireless -Original Message- From: [EMAIL PROTECTED] Date: Fri, 13 Oct 2006 15:35:20 To:[EMAIL PROTECTED] Cc:Patrick W. Gilmore [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: Re: 200K prefixes - Weekly Routing Table Report On Thu, 12 Oct 2006 00:02:32 -, =?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. :)
Re: 200K prefixes - Weekly Routing Table Report
On Thu, 12 Oct 2006 00:53:37 -, 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*. pgpLY3a6sG9XE.pgp Description: PGP signature
Boeing's Connexion announcement
I just got email that some of you may have also received, talking about the end of the service, reasons, etc. The interesting piece is that the service will be free from now through Dec 31 when they turn off the system. Their homepage has a new link so you can sign up in advance, and then use the system when you fly on any equipped airline free. http://www.connexionbyboeing.com/ They say that there is currently no suitor. It sure would be nice if there was one. Maybe the Connexion folks on the list could tell us what is needed to make it work on the network side - I'm sure we have enough resources between us to handle that. And there are a number of aircraft that already have the equipment... /rlj
Re: Boeing's Connexion announcement
Hello; On Oct 13, 2006, at 4:52 PM, Rodney Joffe wrote: I just got email that some of you may have also received, talking about the end of the service, reasons, etc. The interesting piece is that the service will be free from now through Dec 31 when they turn off the system. Their homepage has a new link so you can sign up in advance, and then use the system when you fly on any equipped airline free. http://www.connexionbyboeing.com/ They say that there is currently no suitor. It sure would be nice if there was one. Maybe the Connexion folks on the list could tell us what is needed to make it work on the network side - I'm sure we have enough resources between us to handle that. And there are a number of aircraft that already have the equipment... You will need sufficient resources to pay for the satellite transponder channels - 14 in all IIRC (or get the service from elsewhere). These are all being given back. Regards Marshall /rlj
Re: Boeing's Connexion announcement
Renesys Todd thinks Panasonic is buying the thing. Sent from my BlackBerry® wireless device
Re: Boeing's Connexion announcement
[EMAIL PROTECTED] writes: Renesys Todd thinks Panasonic is buying the thing. As I understand it, Panasonic's product is different, cheaper, and not a turnkey service (they don't have their own satellite transponder constellation). It is aimed at nation-states, not the commercial market. ---rob
Re: 200K prefixes - Weekly Routing Table Report
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_
Re: Boeing's Connexion announcement
At 17:39 -0400 13/10/06, Robert E.Seastrom wrote: As I understand it, Panasonic's product is different, cheaper, and not a turnkey service (they don't have their own satellite transponder constellation). It is aimed at nation-states, not the commercial market. Not according to this news story. (Full text below) http://www.shephard.co.uk/Inflight/Default.aspx?Action=-1000945703ID=78b42b71-21f5-4d2e-8703-6387a7a39a0b They are contracting to airlines and will proceed if they can get 500 planes guaranteed by the end of the year. f INFLIGHT ONLINE EXCLUSIVE: Panasonic reaches for the Connexion torch September 19, 2006 - JUST when the Inmarsat community was relishing the prospect of an unobstructed run at the passenger broadband market, Panasonic has announced a plan to take up where Connexion by Boeing left off. The IFE giant has no intention of rushing in, though, and will not launch unless it has commitments covering a critical mass of aircraft. We have a complete system designed, developed and ready to go, strategic marketing director David Bruner told Inflight Online at the WAEA show in Miami Beach last week. But we're determined to avoid one of the things that brought Connexion down - lack of an initial fleet big enough to assure acceptable pricing for the airlines. Panasonic has set about securing agreements covering a minimum of 500 aircraft in the next 60 days. That schedule is being driven by the need to be ready to serve ex-Connexion airlines within a tolerable time after the discontinuation of that service by the end of the year. We can't drag our launch decision on until, say, February, Bruner said. There will inevitably be a dark period between the end of Connexion and the start of our service, and we want to keep that as short as possible. We already have 150 aircraft committed and feel confident we'll make the 500. But if we're falling badly short in 60 days' time we will not go. Early takers would enjoy significant advantages over airlines that were slower of the mark, Bruner said. In return for a minimum five-year commitment we'll reward our launch customers with very preferential service pricing, and they will also get priority access to bandwidth. Panasonic's standard wholesale price to the airlines would represent a comparatively small premium on terrestrial broadband access tariffs, Bruner said. So far we are seeing little indication that the airlines are planning to mark this up for passengers. It's a service they want to offer - they don't currently see it as a revenue-generator. The new offering is designed to be as attractive as possible to airlines that are already equipped for Connexion. Our solution for them is to replace only the modem on the aircraft and leave all the rest of the hardware, including the antenna, in place, said Bruner. That will spare them the expense of reversing the Connexion installations and then putting in our definitive equipment suite. That includes a compact Ku-band antenna from Californian-based L-3 Datron Advanced Technologies. Another L-3 Communications operation, the Linkabit division, is supplying the modem. Both are already fully developed for US military applications and have been modified for civil use by removing the encryption provision. Working with an existing Ku-band satellite system, the hardware is capable of delivering 12Mbit/sec to the aircraft and 3Mbit/sec in the opposite direction, according to Bruner. Panasonic has selected a single Ku-band satellite operator to provide transponder capacity and geographical coverage at least equivalent to Connexion's. With an initial fleet of 500 aircraft we would anyway pay significantly less for transponders than Connexion, Bruner pointed out. But our technical solution will also be more efficient than theirs, allowing us to put more traffic through each transponder and thus reduce our total requirement for satellite capacity. Panasonic saw itself as a system designer and integrator and had no intention of incurring the costs associated with being a service provider, Bruner said. The as yet unidentified satellite operator would be responsible for system management, operation and capacity planning, and Panasonic is in talks with a global wireless roaming company for the provision of services such as customer care, billing and retail promotion. We're intent on learning from what happened to Connexion, said Bruner. 9/11 lost them their start-up fleet, and after that they were always struggling to catch up. Our onboard equipment is lighter and cheaper, and our approach to buying transponder capacity is altogether more economical. We think these advantages will persuade the airlines and that in a couple of months' time we'll be ready to go ahead. Should the magic 500 not be achieved, however, Panasonic will continue to look for another way into connectivity. If Ku-band proves not to make sense after all, then we'll go down another path,
RE: 200K prefixes - Weekly Routing Table Report
Maybe reboot all our routers at once or something? Who wants to go first...? Then again, maybe better not... philip -- I suspect if we do this, when things 'come back up', we'll be under 200k. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net
Re: 200K prefixes - Weekly Routing Table Report
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
RE: 200K prefixes - Weekly Routing Table Report
I'll bet you nickels to doughnuts that it won't make much of a difference -- in the fact that too may end-ASs originate specifics to attempt to engineer their traffic - ferg -- Alex Rubenstein [EMAIL PROTECTED] wrote: Maybe reboot all our routers at once or something? Who wants to go first...? Then again, maybe better not... philip -- I suspect if we do this, when things 'come back up', we'll be under 200k. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: 200K prefixes - Weekly Routing Table Report
On Sat, Oct 14, 2006, Fergie wrote: I'll bet you nickels to doughnuts that it won't make much of a difference -- in the fact that too may end-ASs originate specifics to attempt to engineer their traffic You could always send those networks a bill for your next BGP-speaking core upgrade. TCAM entries are expensive y'know. From what I've seen here and other lists there seems to be a good financial reason now to aggregate thanks to implementation choices by vendors and purchasing choices by providers. Adrian (239k is enough for everyone, or something.)
RE: 200K prefixes - Weekly Routing Table Report
On Sat, 14 Oct 2006, Fergie wrote: I'll bet you nickels to doughnuts that it won't make much of a difference -- in the fact that too may end-ASs originate specifics to attempt to engineer their traffic We got hit by this a couple of months back. We had held out from doing policy based routing for many many years, but the sheer number of small routes grew to the point where we couldn't handle the full routing table and run DCEF at the same time. We were kind of forced into it. Last I knew, we accepted anything down to a /24 for Arin allocations, and dropped everything below the minimum allocation size for all the other registries. So far, it has been working great for us, and we were able to buy another year or two out of our Cisco gear. But I can see the end of the line coming and I believe we are going to need to replace our core routers sooner rather than later. Sigh -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
Re: ISOI II - a DA Workshop (announcement and CFP)
The second Internet Security Operations and Intelligence (ISOI) DA workshop will take place on the 25th and 26th of January, 2007. It will be hosted by the Microsoft Corporation, in Redmond WA. An after-party dinner will be hosted by Trendmicro. Hi again guys. Some clarifications are in order as under the charter, blatant product advertising is not allowed, and my usual pinger at the admin team who loves to try /kick me for obscure judgements such as discussing religion (?!), just rang. Much like in July, when the NANOG community pulled much of the weight of making this workshop happen (look at the July archives for details), this second workshop is a nanog community meeting, mostly for the closed operational communities that started under NANOG. It is no product. Further, it takes no revenue - Attendance is completely free of charge. The charter has not been broken. My apologies to the community at large for not clarifying these issues in my previous email. This email was a clarification under the charter, and an apology for not making it clearer to the community before now. Thanks, Gadi.
