- Test - lists.nanog.org

The Cidr Report
by Tony Bates 15 Jan '99

15 Jan '99

This is an auto-generated mail on Fri Jan 15 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 15Jan99 0) General Status Table History ------------- Date Prefixes 080199 54976 090199 54679 100199 54744 110199 54918 120199 54860 130199 54884 140199 55099 150199 55155 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4408 Number of ASes announcing only one prefix: 2168 (1156 cidr, 1012 classful) Largest number of cidr routes: 355 announced by AS3561 Largest number of classful routes: 1013 announced by AS701 1) Gains by aggregating at the origin AS level --- 15Jan99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 389 144 245 63.0% UNKNOWN AS701 1013 860 153 15.1% UNKNOWN AS2493 319 173 146 45.8% UNKNOWN AS174 650 536 114 17.5% UNKNOWN AS5668 129 35 94 72.9% UNKNOWN AS3749 157 65 92 58.6% UNKNOWN AS4200 178 91 87 48.9% UNKNOWN AS1267 111 30 81 73.0% UNKNOWN AS4755 147 74 73 49.7% UNKNOWN AS4293 208 137 71 34.1% UNKNOWN AS549 218 152 66 30.3% UNKNOWN AS4740 388 326 62 16.0% UNKNOWN AS8517 134 75 59 44.0% UNKNOWN AS1221 395 336 59 14.9% UNKNOWN AS7657 142 87 55 38.7% UNKNOWN AS7545 111 58 53 47.7% UNKNOWN AS72 89 37 52 58.4% UNKNOWN AS3493 252 200 52 20.6% UNKNOWN AS7046 238 187 51 21.4% UNKNOWN AS1239 531 484 47 8.9% UNKNOWN AS10928 96 49 47 49.0% UNKNOWN AS7496 74 28 46 62.2% UNKNOWN AS577 210 164 46 21.9% UNKNOWN AS852 175 132 43 24.6% UNKNOWN AS719 452 409 43 9.5% UNKNOWN AS3221 84 42 42 50.0% UNKNOWN AS803 71 35 36 50.7% UNKNOWN AS6897 62 27 35 56.5% UNKNOWN AS7122 109 75 34 31.2% UNKNOWN AS2764 327 294 33 10.1% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

NRIC meeting report
by Sean Donelan 15 Jan '99

15 Jan '99

I was in Washington DC yesterday (January 14) and had a choice. I had some free time and could either spend the afternoon at the Senate watching the trial, or I could go over to the FCC and watch the NRIC meeting. I choose the NRIC meeting. The Network Reliability and Interoperability Council, chaired by Bill Armstrong chairman of AT&T, moved along pretty quickly. Most of the focus was on Year 2000 issues telco issues. No great surprises, like most industries, most reports were positive were positive about the industry. Most telephone companies in the USA are on track to completing their Year 2000 project on time, and there are no PSTN to CPE year 2000 problems. Most of the problems were called "second-order" affects. For example, your T1 line and demarc have no Year 2000 issues, but your router or super-smart CSU/DSU might have some. POTS (plain old telephone service) seemed most unaffected. In other words a plain voice line with no options, and a Western Union 2500 telephone set. Its when you get into POTS+ services issues show up. The phone line works, but a fax machine may print the wrong date at the top of the fax page. 9-1-1 calls will go through, but some secondary PSAP equipment (e.g. GIS map systems, dispatching, voice recorder timestamping, etc) might have a year 2000 issue. A repeated theme of the meeting was the second-order problems were the customer's responsibility, and the customer needed to take action to fix them not the phone company. Things were pretty much focused on traditional wireline carriers. Very little was said about wireless, and there was no representation from new things such as the Internet or ISPs. Bill Armstrong reported he as sent two letters out, but received essentially no response. I'm not sure who Mr. Armstrong sent the letters to. I know I haven't ever received one. But I'm was amused to hear I'm not the only one who has trouble getting information out of ISPs :-) I'm not sure how many people on the Council realized it, but it was interesting to watch the Internet being transformed from a convenience to a critical component. Although neither the NRIC nor the FCC seem to know how to communicate with the ISPs, an amazing amount of information and contingency plans are primarily being distributed via the web. But there seems to be no contingency plan for keeping, or restoring the web operation. The contingency plans that do exist, currently exclude Internet service providers unless they happen to be part of a traditional wireline facility based provider. But even then, I've noticed the ISP NOC and the wireline NOC's at the same provider have no contingency plan for communicating with each other. I know, you've heard me beat that drum before. The final part of the meeting was the 1998 annual report from the Network Reliability Steering Committee. The full report is on the ATIS site, but a few highlights. You should read at least the last page on the AT&T frame-relay outage. The frame-relay part of the outage was only important in it caused congestion on the switched network when all the remote sites dialed up their backup lines at the same time. This year NRSC did a root cause analysis across all their outages and found "Procedural Errors" were the top root cause of 32% of all outages. DACS problems are continuing to increase, with 1998 being the highest year yet. Facility failures and CO power problems were continuing areas of concern. The NRIC committee asked the NRSC to track if the National One-Call legislation passed last year had any affect on the number of cable dig-ups. The NRIC web site is <http://www.nric.org/>. A number of reports and presentations are online. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Solution: Re: Huge smurf attack
by Peter Swedock 15 Jan '99

15 Jan '99

On Jan 13, 1:23pm, Phil Howard wrote: > > Filtering .0 and .255, or filtering echos or ICMPs, are all indeed a form > of "fixing" the symptom. These things are being done because fixing the > cause isn't practical. > > But what is the cause? Is it that kids with scripts will attack and try > to bring down an IRC server or the network that hosts it? Or is it that > they have the scripts in the first place? Or is it that they are using > networks that allow them to do this in the first place? I think blamin' the 'scriptkidz' in this instance isn't accurate. I think this incident had a political component that is overlooked here, and one that requires discussion. And that this smurfing was, quite possibly, an answer to that political component. I'm speaking about the "Nuremburg Files" which is downstream of Mindspring. For those of you who don't know, this page is a listing of abortion providers, clinic workers and their respective spouses. Those abortion providers and clinic workers who have been killed are struck-through on this page, those who have been wounded, or who have stopped providing abortions for whatever reason, are grayed out and those remaining are, for lack of a better term, targeted, through the collection of personal information (licsense plate numbers, home addresses, phone numbers, etc...) I bring this up, not to discuss content, but because a lawsuit has been brought, and which began Friday, against this page charging that it is a hit-list that crosses the line of free speech into incitement to violence. The suit has received some national attention (was prominently featured on the CNN webpage) and appears to be, at present, ground zero for the pro-life/pro-choice debates... Given all that, is it hard to beleive that some-one, moderately skilled in networking but extreme in political views, attempted to shut down this page by shutting down Mindspring? This is the real world, people. This isn't the goodgeeks vs. the skriptkiddiez in their own private internet bubble. It is entirely plausible (even likely, given the timing of the case opening Friday, the subsequent publicity and the "huge smurf attack" Saturday...) that this was a political act, and guess what... we're squeezed in the middle. It ain't about which side of the debate any on NANOG will fall on, but the fact that the debate may be falling on us. > The cause of burglaries and thefts is bad people. But the cause of political terrorism is extreme people. I think that, if this smurf attack was in response to the web page "The Nuremburg Files", it is an act of terrorism in response to an act of terrorism: that is to say the page is extreme, so why do we not expect responses to it to be extreme? And, in the middle, network engineers putting out the fires... networks being the battlegrounds that these people have chosen. > I admire Mindspring's position of making Internet access unrestricted. > But what is the real motivation? Is it the goal of "perfect IP" or is > the business case of decreasing tech support costs? They are, afterall, > in the business of providing consumer dialup access, and as we all know > that line of business is very costly in areas of tech support. Network > attacks are also a real cost. I would suggest that treating some of the > symptoms, at least for now, will cut some costs until the day that we > can achieve the utopian goal of the perfect solution to the cause. But if you want "unrestricted internet access" you'll get pages like "The Nuremburg Files" and you'll get people who object to that... I don't know what the solution is... but I do think we'll all be better off opening our eyes to the situation, rather than simply blaming the 'skriptkiddiez'. Peace, Petr -- "Everything should be made as simple as possible, but not simpler" A. Einstein Petr Swedock, Associate Engineer | Network Operations ,o __|-. GTE INTERNETWORKING, POWERED BY BBN ,_~o/ \/ \ ph: 781.262.6300/781.262.6541 |/ | fax: 781.262.6234 / > | ' ` | email: pswedock@bbnplanet.com/pswedock@gtei.net | ______________________________________________________________|

10 15

Anyone with a clue from Concentric?
by Vadim Antonov 14 Jan '99

14 Jan '99

Hi -- is there anyone with a clue from Concentric? The reverse DNS zones at Concenric are hopelessly screwed up and the only DNS person i was able to get hold of doesn't seem to know what he's doing. Please respond personally, and excuse me for bringing that to the list. --vadim

1 0

Re: Performance problems between sprint and uunet?
by jprovo＠ma.ultranet.com 14 Jan '99

14 Jan '99

>Apologies for bothering the list, but we have had tickets open with [snip] >Is anyone else seeing this? Yes, for quite some time. There's apparently an interconnect upgrade planned/in processes/in molasses. Cheers, Joe -- Joe Provo, Network Architect 508.229.8400 x3006 Commercial Internet Services Group Fax 508.229.2375 UltraNet Communications, Inc., an RCN Company <jprovo(a)ultra.net>

1 0

Denver update
by Susan R. Harris 14 Jan '99

14 Jan '99

Greetings everyone - just wanted to let you know that we've made a couple of scheduling changes for the Denver NANOG meeting. As you know, the BGP routing tutorials by Howard Berkowitz and Avi Freedman will start at 1:00 p.m. on Sunday afternoon, Jan. 31. And, following suggestions from many of you, we'll be ending a bit earlier on Tuesday, most likely at noon or early in the afternoon. We've scheduled a few new presentations, and you'll find an update here: http://www.nanog.org/mtg-9901/topics.html Questions, comments welcome, send 'em to nanog-support(a)nanog.org. See you in Denver, where there CAN'T BE as much snow as we have in Michigan ...

1 0

Performance problems between sprint and uunet?
by Fletcher E Kittredge 14 Jan '99

14 Jan '99

Apologies for bothering the list, but we have had tickets open with both parties without resolution. For the last few weeks, we have been seeing performance issues between sprint and uunet. We have not been able to determine anything which would be unique about our configuration. The symptoms are a 400ms latency between Sprint and UUnet routers and a 25% packet loss. An example trace fragment is: 2 Serial4-1-1.GW1.BOS1.ALTER.NET (157.130.4.25) 6.810 ms 9.343 ms 10.909 ms 3 123.ATM2-0.XR1.BOS1.ALTER.NET (146.188.176.226) 11.137 ms 10.868ms 17.13 5 ms 4 191.ATM3-0.XR1.EWR1.ALTER.NET (146.188.176.133) 22.651 ms 21.483ms 14.98 8 ms 5 193.ATM1-0-0.BR1.EWR1.ALTER.NET (146.188.176.49) 12.580 ms12.849 ms 16.1 78 ms 6 sl-pen-11-h3.sprintlink.net (137.39.44.130) 434.196 ms 432.565ms 438.700 ms 7 sl-bb11-pen-0-1.sprintlink.net (144.232.5.9) 451.170 ms 464.872ms 426.18 1 ms 8 sl-bb12-pen-10-0.sprintlink.net (144.232.5.158) 488.077 ms * 419.564 ms 9 sl-bb11-fw-3-0.sprintlink.net (144.232.8.157) 444.772 ms 462.465ms 457.6 47 ms 10 sl-gw15-fw-8-0-0.sprintlink.net (144.232.11.82) 499.928 ms476.629 ms 481 .154 ms Is anyone else seeing this? thanks! fletcher

1 0

Re: Smurfing and IP filtering
by Jeff Mcadams 14 Jan '99

14 Jan '99

Thus spake Steven J. Sobol >On Thu, Jan 14, 1999 at 01:30:01PM +0300, Alex P. Rudnev wrote: >> There is RFC recommendation for the router. >> Why there is not RFC describing the policy (mandatory!) for the ISP? >An RFC is a recommendation. A typical RFC usually ends up being a de-facto >standard, however it does not have the force of law. >Backbone operators have to start putting pressure on their downstreams to >fix their router configs. The downstreams have to put pressure on THEIR >downstreams, etc. The only way to get everyone to fix their routers is to >write clauses into contracts saying "if your network ends up being a smurf >amplifier, and we find that your routers are misconfigured, you will be >disconnected from the Net without any kind of refund or credit for your >downtime, and you will remain down until you fix things." >That, and education, will do the trick. True, but publishing an RFC to add some weight to that might help in that education effort and help the upstreams convince their downstreams that it needs to be done. A well written RFC might also be a document that the upstreams could send to the downstreams to help them understand actually what's going on with the situation and help them understand why it needs to be fixed (why in the greater overall good scheme of things, though why in the "do this or we're axing your connection" will help as well). If the issues are outlined in a nice format that people can read, I suspect you'll get less opposition from downstreams that don't want to muck with their already fine (as far as their performance can tell) router configs. While I agree...education, and threatening to ax connections *should* do the trick, the sad truth here is that before you can deal with router configs, you're dealing with humans in these organizations that you have to convince this is a good thing to do. I believe that an RFC would *help* to do that. No, it shouldn't be necessary, but if there's very little downside to it (and I don't see much downside to publishing an RFC...maybe a Best Current Practices or something), and there's some upside to it in that it might help convince some recalcitrant or ignorant network operators out there to change their router configs...well then, I say, let's do it. -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

2 1

RE: Smurfing and IP filtering
by Scott McGrath 14 Jan '99

14 Jan '99

That would be a good starting point for the more sophisticated users however most small networks have very uneven clue distribution so I believe something in a FAQ format would be more approachable to the small ISP/Network operator and therefore more likely to be implemented even if they did not fully understand the configuration. We also need to create documents which explain what each of the configs do > -----Original Message----- > From: Chris Cook [SMTP:ccook@netasset.com] > Sent: Wednesday, January 13, 1999 1:28 PM > To: 'Scott McGrath' > Subject: RE: Smurfing and IP filtering > > This is a really good idea. A thought on what to start with would the > Cisco IOS Essentials Guide that was mentioned about a month ago. I have > begun implementing parts of this on our edge devices (mostly cisco's). It > could probably be simplified and amended (for things like Bay hardware). > > Chris Cook > > NetAsset, LLC > Fresno, CA > > -----Original Message----- > From: Scott McGrath [mailto:SMcGrath@YBP.com] > Sent: Wednesday, January 13, 1999 9:08 AM > To: nanog(a)merit.edu > Subject: Smurfing and IP filtering > > > I have been lurking on the Smurfing issue for a while > > In my experience most tier 2&3 ISP's when they sell T1 access to the > internet just deliver a basic configuration > on the router with NO route filters whatever they do not even put the most > basic access restrictions on the router > We as a group should create a best practices document (with sample > config's) > to increase the distribution of cluefulness > across the network as a whole to reduce the incidence of these problems > and > make less firefighting neccessary for ourselves. > > > Scott Mc Grath > Yankee Book Peddler > 999 Maple Street > Contoocook, NH 03229 > Phone: 603 746-3102 x3350 > Fax: 603 746-5628 > > mailto:smcgrath@ybp.com

3 3

latency vs. packet loss
by jzeeff＠whs.verio.net 14 Jan '99

14 Jan '99

How well does latency correlate to packet loss on the Internet? For example, if one were to pick one of several randomly placed sites on the net based on lowest latency to/from point x, what percentage of this time would this also yield the site with the lowest packet loss to/from point x? My guess is that the correlation is high (due to typical buffer sizes).

2 2