- Test - lists.nanog.org

Re: aggregation tool wanted
by Randy Bush 29 Nov '98

29 Nov '98

>> unfortunately, the actual data as paths can differ >> >> 133.10.0.0 2914 2907 >> 133.11.0.0 2914 2907 2501 >> 155.162.0.0/15 2914 >> 155.164.0.0/14 2914 >> >> so, what i would like is a tool which takes something like the latter syntax >> and tells me what the origin ass could aggregate. i.e. i am specifically >> not inclined to proxy aggregation at this point. > > So in this case, all you'd get back is: > > 133.10.0.0 2914 2907 > 133.11.0.0 2914 2907 2501 > 155.162.0.0/15 2914 > 155.164.0.0/14 2914 > > because the origin AS for each block couldn't aggregate the above blocks > further? correct. > What is CIDRadvisor? A lookup in some search engines doesn't turn up > anything... part of RAToolset randy

2 1

NON-OPERATIONAL: A note of thanks to ANS
by John M. Brown 29 Nov '98

29 Nov '98

I just wanted to say thanks to the NOC staff at ANS. Since we have been adding several new customer routes to our BGP announcements, they have been wonderful in responding to our questions, and our help. And we are not even a customer of ANS. How does this tie in with operational issues, you might ask? Well, if all NOC's would respond in the manner we have seen from ANS, then life would be easier. Saying THANKS is also a plus since it recognizes people that do good things. Its people that run the Net. And on this list there are sometimes way to many people bitching about something, including me. So I felt it was operationally important to say thanks. Not all of you may agree, and we don't need a thread on this. jmbrown(a)ihighway.net

2 1

Better flap damping algorithm
by Vadim Antonov 29 Nov '98

29 Nov '98

The drafts are at: http://www.civd.com/~avg/flap-rfc.txt (text version) http://www.civd.com/~avg/flap-rfc.ps (PostScript) PostScript version is recommended (nice pictures :) I would appreciate comments and corrections (spelling, grammar, style too); please do not send them to the mailing lists, but directly to me. Thanks! --vadim

1 0

Re: ORBS: Another Vigilante Group
by Bob Allisat 28 Nov '98

28 Nov '98

Larry writes: > You are wrong, these people *are* elected. They are elected by > the millions of users who do not want spam. The answer is simple > but for some reason you refuse to see it. I would gladly grant > all necessary authority to my ISP to act in any way that benefits > me and my wishes. Nonsense. Democratic forums are open, transparent, accountable, feature regular elections, laws, constitutions and so on. There are no such institutions on the net. There are technically capable but otherwise unsophisticated lads running around pretending they are the law. They aren't. Larry continues: > As for your characterization of Paul Vixie, I have only this to > say. There's an old saying in the legal community that goes like > this: "If the law is on your side, argue the law. If the facts > are on your side, argue the facts. But if neither the law *or* > the facts are on your side, then assassinate the character of > your opponents". > > It seems pretty clear to me that your only recourse is to assault > those people who would work in the interests of the greater good > of the users of the Internet, or, more to the point, who would > disagree with you. On the surface, you appear to be quite the > hypocrite, attacking others for allegedly...attacking others. In a civil forum I have drawn into question the activities of persons acting in what I believe to be unethical and unscrupulous manners. I have attacked no-one and interfered with no person's civil liberties, rights and/or freedoms. Whereas Mr. Vixie regularly trades in the violation of these rights. With nothing more to back him up but technical know-how and a gang of fellow geekthugs. A very unfortunate situation I suspect time will alter to a conclusion more in line with our traditons or democracy than with Vixie et al's propensity to totalitarian despotism. Respectfully, Bob Allisat Free Community Network _ bob(a)fcn.net . http://fcn.net http://fcn.net/allisat _ http://fcn.net/draft

4 5

The Cidr Report
by Tony Bates 27 Nov '98

27 Nov '98

This is an auto-generated mail on Fri Nov 27 12:00:00 PST 1998 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 27Nov98 0) General Status Table History ------------- Date Prefixes 201198 54986 211198 55088 221198 55084 231198 55066 241198 55125 251198 55118 261198 54086 271198 54161 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: 4262 Number of ASes announcing only one prefix: 2087 (1105 cidr, 982 classful) Largest number of cidr routes: 339 announced by AS3561 Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 27Nov98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 349 153 196 56.2% BCnet Backbone AS3749 229 73 156 68.1% TECNET AS2493 341 193 148 43.4% iSTAR Internet, Inc. AS701 1002 867 135 13.5% Alternet AS1785 535 400 135 25.2% NYSERNet Backbone AS174 686 555 131 19.1% Performance Systems International AS4200 188 96 92 48.9% AGIS (Apex Global Information Ser AS5668 126 39 87 69.0% Century Telephone Inc. AS1267 109 30 79 72.5% IUNET-AS AS4755 133 59 74 55.6% Videsh Sanchar Nigam Ltd. India AS4293 207 135 72 34.8% IMCI AS549 224 156 68 30.4% ONet Backbone AS4740 390 330 60 15.4% Ozemail Pty Ltd (ASN-OZEMAIL) AS8517 127 71 56 44.1% UNKNOWN AS7046 256 200 56 21.9% UUNET-CUSTOMER AS1221 382 327 55 14.4% AARNET-AS AS6335 71 19 52 73.2% NTRNET AS7545 117 66 51 43.6% TPG Internet Pty Ltd AS72 88 40 48 54.5% Schlumberger Information Network AS1239 529 481 48 9.1% SprintLink Backbone AS7657 138 92 46 33.3% The Internet Group Limited AS803 77 33 44 57.1% SaskNet Backbone AS7496 72 30 42 58.3% Power Up AS3221 84 42 42 50.0% RIPE-ASNBLOCK4 AS852 169 128 41 24.3% AGT Advance Communication AS10928 89 48 41 46.1% UNKNOWN AS719 440 402 38 8.6% LANLINK-AS AS7122 115 77 38 33.0% MTS ADVANCED Network Policy AS3804 157 124 33 21.0% Bell Solutions AS2707 65 32 33 50.8% WEC 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

[test, drop it]
by Alex P. Rudnev 27 Nov '98

27 Nov '98

[test only, sorry]

1 0

Re: NSI policy on lame delagations
by Paul Vixie 26 Nov '98

26 Nov '98

> Given (for example) PostGreSQL, is there any reason why someone hasn't > ported the algorithms of BIND on top of something like it? It seems to > me that it ought to be possible to keep a nameserver running whilst one > is doing maintenance on it... the line of people who have asked for this would stretch out the door and into the street. bind runs from memory rather than from disk, because it has to be able to answer at wire speed for large values of "wire". we're working on a hierarchical storage system, basically a memory cache with LRU, backed by a database. we're also working on a way to load from sql databases into memory rather than always having to load from disk. it's likely that the second of those two projects will be complete a year or so before the first :-). in 8.1.2++, though, the goal is to be able to check and/or reload a zone without having to stat() all the others. for someone with 50K zones on board, this should be a huge speedup. -- Paul Vixie <paul(a)vix.com>

9 10

RE: SOLVED! The cause of puzzling TCP (eg. WHOIS) connection failures with some InterNIC.net hosts
by Rob Gilde 25 Nov '98

25 Nov '98

Mark Kosters writes: | | On Fri, Nov 20, 1998 at 04:25:11PM -0500, Greg A. Woods wrote: | > The problem has to do with the failure of a host to fragment larger | > packets on demand (i.e. when the other host sends an ICMP "needs frag" | > notification). This may be because the ICMP packet never gets through | > (perhaps someone who didn't understand TCP/IP and ICMP and everything | > else related implemented a filter on all "abnormal" ICMP packets); or it | > may be because the receiving host doesn't understand the ICMP "needs | > frag" request (and also doesn't implement path MTU discovery, or have I | > got that backwards?). | > | > No matter what the problem really is, I'm sure a *lot* of people would | > be much happier if this problem were fixed, specifically for the WHOIS | > service (though I've also had troubles receiving HTTP too). I got quite | > a few replies about similar experiences when I first posted about this | > on NANOG recently. | | Thanks Greg for the good information. | | The InterNIC load balancers (BigIP made by F5 Labs) do have a problem with | path MTU discovery. We have taken a short term fix of turning off path MTU | discovery on the hosts behind BigIP until F5 issues a fix. | | Regards, | Mark | | -- | | Mark Kosters markk(a)internic.net InterNIC Registration Services | Firstly, thanks to Greg Woods and Mark Kosters for isolating this problem. Now that they have, the fix is fairly straight-forward, and we'll be working with Mark to deploy that shortly. We will make available a BIG/ip software patch that allows path MTU discovery for servers situated behind it. Whenever BIG/ip receives an ICMP "needs frag" message, it will replicate it to each of the servers that may need it at that time. This replication is necessary because a specific client may have concurrent connections to more than one server behind BIG/ip. By their very nature, load balancers do not play by the same rules as "normal" network devices such as routers and hosts. Except where we have implemented specific support, BIG/ip blocks all ICMP messages from reaching servers situated behind it. Chris Mauritz writes: | | Actually, this isn't a BigIP problem. It's a BSDI problem (the underlying | OS for the BigIP box). I believe BSDI has a patch available for BSD/OS 4.0 | (mayabe even 3.1). While you can't benefit from this patch directly, you | can perhaps nudge your F5 rep about expediting a patch for your boxen. | Although BIG/ip is based, in part, on BSDI, these patches are not applicable because BIG/ip's packet processing logic is very unique. So in this case, it *is* BIG/ip's problem. It's not the first problem, and it won't be the last. As Internet applications and infrastructure evolve, and BIG/ip's installed base grows and feature set expands, we are constantly discovering new ways to improve the product. The best suggestions come from our customers and from experts like the NANOG members. If anyone has any questions or comments about F5 Labs products (including their behavior on the net), please feel free to contact me directly. Thanks! Rob Gilde Principal Engineer F5 Labs, Inc. rob(a)f5.com 206-505-0800

1 0

Internet Data Center Notes from NANOG14
by William B. Norton 25 Nov '98

25 Nov '98

Hi all - Thanks to everyone who participated in the Internet Data Center BOF at NANOG 14. As promised, I wrote down the items folks contributed to the white boards and tried to add some context to them. Since folks added stuff to the lists when we moved upstairs-I wasn't involved in the discussion and the notes are my best guess at your additions. Corrections/clarifications welcome. Here is the URL: http://www-personal.umich.edu/~wbn/DataCenterNeedsNotes.htm It would be good to turn these notes into better prose for the community that intend on building/contracting/choosing facilities for housing Internet gear. Let me know if you'd like to help write that up. Cheers - Bill

1 0

Re: About last smurf floods - additional info
by Paul Ferguson 25 Nov '98

25 Nov '98

At 04:25 PM 11/25/98 +0300, Alex P. Rudnev wrote: >You are not right, everything should be done - clearing trojans from your >servers, filtering frauded SRC addresses (most important issue), >decreasing SMURF amplifyers, lawsuits agains the hackers. It's amazing, >but we have not ANY official complain from foreign countries (foreign >companies) through I have asked such complain any time I'v write about >the broken system/network. As aside, ingress filtering (a la RFC2267) or unicast RPF checks work quite well in filtering out traffic originating from bogons. Both of these are relatively simple to invoke. The key issue here is that (it appears that) some networks are not taking "socially responsible" actions beacuse of either (a) laziness, (b) ignorance, or (c) both. - paul

1 0