- Test - lists.nanog.org

The Cidr Report
by cidr-report＠potaroo.net 28 Feb '03

28 Feb '03

This report has been generated at Fri Feb 28 21:46:34 2003 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 Prefixes CIDR Agg 21-02-03 119400 85542 22-02-03 119615 85397 23-02-03 119379 85455 24-02-03 119479 85425 25-02-03 119470 85630 26-02-03 119690 85676 27-02-03 119740 85694 28-02-03 119708 85768 AS Summary 14678 Number of ASes in routing system 5782 Number of ASes announcing only one prefix 1604 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73080832 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA 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'). --- 28Feb03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 119861 85734 34127 28.5% All ASes AS3908 1084 568 516 47.6% SUPERNETASBLK SuperNet, Inc. AS18566 491 8 483 98.4% COVAD Covad Communications AS701 1604 1151 453 28.2% ALTERNET-AS UUNET Technologies, Inc. AS4151 532 105 427 80.3% USDA-1 USDA AS4323 533 169 364 68.3% TW-COMM Time Warner Communications, Inc. AS7018 1385 1025 360 26.0% ATT-INTERNET4 AT&T WorldNet Services AS7843 556 224 332 59.7% ADELPHIA-AS Adelphia Corp. AS6197 485 157 328 67.6% BATI-ATL BellSouth Network Solutions, Inc AS7046 559 244 315 56.4% UUNET-CUSTOMER UUNET Technologies, Inc. AS1221 1121 816 305 27.2% ASN-TELSTRA Telstra Pty Ltd AS1239 969 686 283 29.2% SPRINTLINK Sprint AS4355 402 119 283 70.4% ERMS-EARTHLNK EARTHLINK, INC AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS705 450 196 254 56.4% ASN-ALTERNET UUNET Technologies, Inc. AS4814 264 15 249 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS6198 439 205 234 53.3% BATI-MIA BellSouth Network Solutions, Inc AS1 662 435 227 34.3% GNTY-1 Genuity AS22291 243 31 212 87.2% CHARTER-LA Charter Communications AS17676 230 26 204 88.7% GIGAINFRA XTAGE CORPORATION AS6347 369 168 201 54.5% DIAMOND SAVVIS Communications Corporation AS2386 478 283 195 40.8% INS-AS AT&T Data Communications Services AS209 528 337 191 36.2% ASN-QWEST Qwest AS4134 304 113 191 62.8% CHINANET-BACKBONE No.31,Jin-rong Street AS690 498 308 190 38.2% MERIT-AS-27 Merit Network Inc. AS2048 258 87 171 66.3% LANET-1 State of Louisiana AS852 599 444 155 25.9% ASN852 Telus Advanced Communications AS7303 240 90 150 62.5% AR-TAST-LACNIC Telecom Argentina Stet-France Telecom S.A. AS22773 182 32 150 82.4% CCINET-2 Cox Communications Inc. Atlanta AS6140 285 136 149 52.3% IMPSAT-USA ImpSat AS6327 187 41 146 78.1% SHAWFIBER Shaw Fiberlink Limited Total 16232 8233 7999 49.3% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Could you check your bogon filter?
by Katsuya Saito 28 Feb '03

28 Feb '03

Hi, Now, we face a serious problem in use following five new APNIC Class B cidr blocks. 1. 221.112.0.0/16 2. 221.114.0.0/14 (actually, we registered 4 class B cidr Blocks to RADB ) I checked "Rob's Bogon list" (http://www.cymru.com/Documents/bogon-list.html) But his lists was already changed in Ver. 1.2. He noted updates as follow. "221/8 allocated to APNIC. Removed from bogon lists" But in actual, I guess some ISP forget updating this. In fact, when http://bgp.potaroo.net/cidr/ checked, there are no bogus routes in Feb, 28, 2003. But 2 days before, according to "http://www.employees.org/~tbates/cidr-report.html", our cidr was in bogus routes lists as follow, Possible Bogus Routes *** Bogus 10.1.1.1/32 from AS(65303) *** Bogus 82.32.0.0/12 from AS5462 *** Bogus 221.6.0.0/17 from AS4134 *** Bogus 221.6.128.0/17 from AS4134 *** Bogus 221.18.0.0/16 from AS17676 *** Bogus 221.23.0.0/16 from AS17676 *** Bogus 221.95.0.0/16 from AS17676 *** Bogus 221.112.0.0/16 from AS17506 *** Bogus 221.113.0.0/18 from AS4685 *** Bogus 221.113.64.0/18 from AS10013 *** Bogus 221.113.128.0/17 from AS4713 *** Bogus 221.114.0.0/16 from AS17506 *** Bogus 221.115.0.0/16 from AS17506 *** Bogus 221.116.0.0/16 from AS17506 *** Bogus 221.117.0.0/16 from AS17506 Still now, ours blocks is not free from some one's router bongon filter. Please check your using bogon lists.......... and Please fixed it if it is possible. Or if you know some another reason of this problem or mistake of my idea, please let me know. Please reply off-list, Thanks, ---Katsuya Saito U's Communications Corp.

1 0

Q: How to avoid retaining "portable" class C?
by scott.davis＠beanfield.com 28 Feb '03

28 Feb '03

I realize this is a little too non-operational for the list, but I stupervise a 750 desktop net with a portable class C when I haven't lost myself in the pub. We use about (approximately) 6 of those 253 useable addr's. I could cut that down to 4, I think. I don't think we're worthy of the cross-ISP portable subnet. The company is nearly 100 years old (in Canada!) but we just use email/user surf. Can anyone share advice about how I might communicate "this is generally bad 'cause of BGP table size" issues to a non-technical manager..? This individual thinks our netblock is a continued reason for his/her employment, as per usual. Off-List replies would be appreciated. (416) 432-4334. Anytime. -- Scott.

1 0

Cidera will be back up
by Ringdahl, Dwight (WebUseNet) 27 Feb '03

27 Feb '03

By midnight, providing the bandwidth challenged UseNet feeds again. WebUseNet will make an announcement of our business deal with Cidera in the near future. We are glad we were able to help save this important resource on the Internet. Dwight Ringdahl WebUseNet

1 0

Re: RIPE Down or DOSed ?
by Dave Israel 27 Feb '03

27 Feb '03

On 2/27/2003 at 10:44:49 -0800, Will Yardley said: > > On Thu, Feb 27, 2003 at 11:09:19AM -0500, kai(a)pac-rim.net wrote: > > > And on a related topic (whois.ripe.net almost unreachable, along with > > the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for > > about 4 days: Level3 was informed, but seems to have some good reasons > > of their own not to fix this.... > > > $ telnet rwhois.level3.net 4321 > > Trying 209.244.1.179... > > telnet: Unable to connect to remote host: Connection refused > > There is no public access to rwhois.level3.net (it worked at one point, > but, accurding to Level3, not intentionally). They say that they don't > have to make this information available to anyone except ARIN. I was > always under the impression that delegations had to be publicly visible, > but looking at ARIN's policy more closely, it seems that the information > only has to be available to ARIN. If the ARIN server recurses properly, you should be able to pull it out that way. So hiding it from everybody but ARIN doesn't make the information unavailable. They're probably sheltering themselves from security concerns in the server. -Dave

1 0

RIPE NCC network affected by the DDoS attack (fwd)
by Daniel Diaz 27 Feb '03

27 Feb '03

------- Forwarded Message Date: Thu, 27 Feb 2003 18:18:25 +0100 From: Andrei Robachevsky <andrei(a)ripe.net> Sender: dns-wg-admin(a)ripe.net To: local-ir(a)ripe.net, db-wg(a)ripe.net, dns-wg(a)ripe.net Subject: RIPE NCC network affected by the DDoS attack Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC ------- End of Forwarded Message

1 0

Re: Remote email access
by Michael.Dillon＠radianz.com 27 Feb '03

27 Feb '03

> Hence there is no space-efficient way of noting an authority > chain, other than entering every single IP address ever assigned, all in > one big data base. > Alas, that ain't feasible. I beg to differ. Essentially, the collective databases of the address registries are the data base that you describe. But... > At a minimum, it is essentially impossible to > keep such a database up to date. You may be right. The ARIN, RIPE and APNIC databases are filled with junk, lies, and inaccuracies. On the face of it this seems to prove that it is impossible to keep the data up to date. However, since there has never been any significant effort to ensure that the databases are accurate and up to date, this could change. If ARIN, RIPE and APNIC were to find some financial and political support, then I believe that they could provide a global authoritative database of all IP address ownership that was reasonably accurate and up to date. If this could be queried by a standard protocol such as LDAPv3 (Referral LDAP) then the distributed database could be queried in much the same way as the distributed DNS is. What would be the point? Well, if my MTA receives a connection on port 25 I could look up the source IP address in the LDAP directory to identify the owner. Since an LDAP directory can contain arbitrary information related to its entries, perhaps I could find out whether or not that source IP is registered as an SMTP server and also retrive the abuse email address of the organization who has registered this address. --Michael Dillon

7 7

RIPE NCC network affected by the DDoS attack
by Andrei Robachevsky 27 Feb '03

27 Feb '03

Dear Colleagues, Starting from 14:00 UTC today, 27 February, RIPE NCC network suffered a large DDoS attack. It was a distributed ICMP echo attack. The attack caused various congestion related problems for the RIPE NCC's network, to the extent that our BGP peering sessions were affected, and non-ICMP traffic was being randomly dropped. The attack was successfully mitigated with cooperation of our peer networks at AMS-IX. Network condition returned back to normal at 16:30 UTC. As a result some of our services, including www.ripe.net (web), whois.ripe.net (RIPE Database), ns.ripe.net (DNS) and ftp.ripe.net (FTP) were not accessible during this timeframe. Now all services are back to normal. Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

Lowering the Homeland Security Advisory Threat Level
by Sean Donelan 27 Feb '03

27 Feb '03

CNN (and most other news sources) are reporting that the Department of Homeland Security is lowering the threat level from "Orange" to "Yellow" later today. There is no sign of any change on the Department of Homeland Security web site yet. Has any ISAC given out information to its members?

2 1

Re: RIPE Down or DOSed ?
by Daniel.Diaz 27 Feb '03

27 Feb '03

Dear all, FYI Since 14:00 UTC today Feb 27, RIPE NCC has been under ICMP DDoS attack. We have been isolating this applying internal measures and coordinating this with our upstream providers to isolate it as soon as possible. We are confident it will be soon mitigated. Thanks and regards. -- Daniel.Diaz Marshall Eubanks <tme(a)multicasttech.com> writes: * * Can anyone else get to ripe.net ? * I cannot seem to access the whois or any other service (my ripe traffic * goes through Sprint). * When I ping peach.ripe.net, I get 90%+ missing packets + "destination * host unreachable" * from inside Sprint. * * * Regards * Marshall Eubanks * -- Daniel.Diaz Operations Manager RIPE NCC

1 0