- Test - lists.nanog.org

IS-IS or OSPF as BGP IGP
by Martin, Christian 17 Jul '98

17 Jul '98

All, Does anyone have any information on redistributing BGP traffic into OSPF versus ISIS? What about just carrying IBGP sessions? My OSPF database is growing, and I'd rather not carry LSAs with BGP routes as well as private routes, etc. Too messy. By introducing ISIS and using it only as a BGP IGP, what can I expect? Experiences with Cisco gear preffered. -Christian

1 0

preliminary 3q98 results
by Bill Manning 17 Jul '98

17 Jul '98

For your consideration. I appologise for duplicates. The 3rd quarter 1998 in-addr audit results. ------------------------------------------------------------------------- Refused are servers who refused to transfer the zone. <REFUSED> Errors were generally related to the following conditions: <timeout> - delegation to the host level e.g. 2.2.0.192.in-addr.arpa. This is also how the CNAME haq works for CIDR delegations so its hard to tell how much of an error this really is. - use of slashes e.g. 0/2.2.0.192.in-addr.arpa. An older method of doing bit-level delegation... - alpha strings e.g. test.2.0.192.in-addr.arpa. - other non-numberics e.g. #???.2.0.192.in-addr.arpa. - failure to fully qualify zones, e.g. the missing "." - event-horizon e.g. behind firewall Other failures seem to be related to server configuration or network reachability of either the end system or the nameservers used in generating the queries. The no-server number is the total of the refused, error, & other rows. inital zone runtime total# #correct no-svr refused error other 3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 42824 4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 66882 1q98 91555 372 h 500397 250107 50.1% 250210 54925 150114 45171 2q98 (1) 112 h 532504 253000 47.5% 279484 124626 31841 123017 3q98 100185 189 h 551631 277878 50.3% 273626 145592 (*) (*) (1) extrapolated from partial/overlapping data (corrupted disk) (*) intermediate results -- --bill

1 0

The Cidr Report
by Tony Bates 17 Jul '98

17 Jul '98

This is an auto-generated mail on Fri Jul 17 12:00:00 PDT 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 17Jul98 0) General Status Table History ------------- Date Prefixes 100798 52359 110798 52365 120798 52291 130798 52391 140798 52359 150798 52389 160798 52656 170798 52681 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 213.102.1.0 from AS3259 *** Bogus 214.0.0.0/8 from AS568 *** Bogus 215.0.0.0/9 from AS568 *** Bogus 216.0.0.0/14 from AS2548 *** Bogus 216.13.0.0/19 from AS6401 *** Bogus 216.13.32.0/19 from AS6401 *** Bogus 216.15.0.0/19 from AS10368 *** Bogus 216.15.128.0/19 from AS7393 *** Bogus 216.16.0.0/19 from AS6304 *** Bogus 216.18.0.0/19 from AS6539 *** Bogus 216.19.0.0/18 from AS4492 *** Bogus 216.22.0.0/19 from AS7960 *** Bogus 216.23.0.0/19 from AS8079 *** Bogus 216.27.0.0 from AS7349 *** Bogus 216.214.0.0/18 from AS7194 AS Summary ---------- Number of ASes in routing system: 3750 Number of ASes announcing only one prefix: 1827 (964 cidr, 863 classful) Largest number of cidr routes: 360 announced by AS3561 Largest number of classful routes: 1143 announced by AS701 1) Gains by aggregating at the origin AS level --- 17Jul98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 485 278 207 42.7% iSTAR Internet, Inc. AS3602 516 311 205 39.7% Sprint Canada Inc. AS701 1143 941 202 17.7% Alternet AS271 340 144 196 57.6% BCnet Backbone AS4293 450 257 193 42.9% IMCI AS3749 223 66 157 70.4% TECNET AS174 731 589 142 19.4% Performance Systems International AS2685 266 161 105 39.5% IBM Global Network - US AS5668 135 49 86 63.7% Century Telephone Inc. AS2764 428 347 81 18.9% connect.com.au pty ltd AS4755 117 41 76 65.0% Videsh Sanchar Nigam Ltd. India AS3221 112 42 70 62.5% EENet Autonomous System AS3804 220 155 65 29.5% Bell Solutions AS7046 228 165 63 27.6% UUNET-CUSTOMER AS4740 401 344 57 14.2% ASN-OZEMAIL (Ozemail Pty Ltd) AS10928 102 45 57 55.9% UNKNOWN AS3403 179 127 52 29.1% TIAC AS8517 123 72 51 41.5% ULAKNET-ASN AS6335 68 19 49 72.1% NTRNET AS72 85 37 48 56.5% Schlumberger Information Network AS1239 540 493 47 8.7% SprintLink Backbone AS719 450 404 46 10.2% LANLINK autonomous system AS4539 71 26 45 63.4% NETROPOLIS AS4200 142 97 45 31.7% AGIS (Apex Global Information Ser AS852 157 116 41 26.1% AGT Advance Communication AS762 118 80 38 32.2% WELLFLEET-AS AS1785 287 249 38 13.2% NYSERNet Backbone AS6392 66 29 37 56.1% MidWest Communications, Inc. AS6181 65 28 37 56.9% FUSE-NET AS549 174 137 37 21.3% ONet Backbone 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

Re: Outages and Nanog
by sob＠academ.com 17 Jul '98

17 Jul '98

There is a "outage-discuss(a)academ.com" list for the discussion of outage announcements. > I remember Stan Barber saying something about one about a year ago, but I > don't remember if anything ever came of it. > > Joe Shaw - jshaw(a)insync.net > NetAdmin - Insync Internet Services > > On Wed, 15 Jul 1998, Mark R. Lindsey wrote: > > > If there is a North-American network-outages list, I'd like to know > > where I could get information about it. > > > > If not, then I'll start one. Several on this list seemed to wig out when > > outages become threads. > > > Mark R. Lindsey, mark(a)datasys.net > > Internet Engineering, DSS Online LLC > > Voice: 912.241.0607; Fax: 912.241.0190 > -- Stan | PGP Key ID: 55CB6421 | Opinions expressed are only mine. Olan | Phone: +1-713-793-0222 | Email: sob(a)academ.com Barber | Fax: +1-713-793-0221 | http://www.academ.com/~sob

1 0

NSI Bulletin 098-009 | Whois problems
by David H. Holtzman 16 Jul '98

16 Jul '98

We've recently experienced two separate problems with whois which may have resulted in slow response and in one case a 24 hour delay in propagation of updates. The first and primary cause was due to a denial of service attack at whois. The initiating location has been temporarily disabled from access to the infrastructure. The second cause was due to excessive internal loading on the back end data base this morning. Those activities have been discontinued. _____________________________________ David H. Holtzman (dholtz(a)internic.net) Sr Vice President of Engineering Network Solutions, Inc.

1 0

Internic database updater foobared?
by Blake Willis 16 Jul '98

16 Jul '98

Howdy, Anybody else notice that the NIC's database hasn't been refreshed in a while? Some customers called me today wondering why their changes weren't working yet, and I noticed that the last update happened over 48 hours ago. blakew(4)[~]> whois internic.net Database last updated on 14-Jul-98 08:32:30 EDT blakew(5)[~]> whois nanog.org Database last updated on 14-Jul-98 08:32:30 EDT Blake Willis CAIS Network Engineering --------------------------------------------------------------------------- Blake Willis 703-448-4470x483 Network Engineer, New Customers blakew(a)cais.net CAIS Internet, a CGX Communications Company ---------------------------------------------------------------------------

4 3

Outages and Nanog
by mark＠vielle.datasys.net 16 Jul '98

16 Jul '98

If there is a North-American network-outages list, I'd like to know where I could get information about it. If not, then I'll start one. Several on this list seemed to wig out when outages become threads. --- Mark R. Lindsey, mark(a)datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607; Fax: 912.241.0190

3 2

RE: NOC communications
by Sean Donelan 16 Jul '98

16 Jul '98

>How about a major oversimplification of a fix. Closed mailing list. One >primary contact for each company is designated and allowed to join the list. >Every 2 weeks (maybe a month?) an email is autogenerated that must be ACK'd >or that companies NOC entry is considered stale. The person on the mailing >list is responsible for ensuring contact info is updated. Uhm, the usual problem is the contact person leaves the company. The exit interview rarely includes updating the contact information. Everyone else will know the information is out-dated, assuming you ban people from setting up procmail to auto-ack the message. But how do you get the replacement's contact information if the replacement doesn't know about the list, database, server, etc and you don't know who the replacement is? In any case, I'd be happy to participate in such a list. Although in some sense you are preaching to the converted. If you would like a sample message, how about something similar to what a previous government contractor used to send every six months or so when they managed the NIC database. Perhaps change the "do not respond," to "respond with 'ok 123456'" to make the procmail folks work a little harder writing their auto-ack scripts. >Date: Tue, 25 Sep 90 01:09:33 PDT >From: HOSTMASTER(a)NIC.DDN.MIL >Subject: Network Administrator Update >To: sean(a)DRANET.DRA.COM > >Dear Network Coordinator, > > Here is the current information pertaining to your network. > Please review it and return any corrections to > HOSTMASTER(a)NIC.DDN.MIL. > > ** If no changes are needed, you do not need to respond to this > message. ** > > The file > > NETINFO:NETWORK-CONTACTS.TXT > > on the NIC.DDN.MIL machine (network address 192.67.67.20) contains > information regarding network contacts for every IP network registered > with the DDN Network Information Center. This file may be FTPed by > invoking FTP at your local host and connecting to NIC.DDN.MIL, using > USERID = 'anonymous', PASSWORD = 'guest'. > > Please allow 8 working days for changes to be processed. > > Thanks, > > Hostmaster Staff > DDN Network Information Center > >----------- > > >NAME of responsible organization: Data Research Assoicates, Inc. > > > Network Name: DRA-STL > Network Number: 192.65.218.0 > > Coordinator: > Donelan, Sean M. (SMD1) sean(a)DRANET.DRA.COM > (314) 432-1100 > > I'm a firm believer in keeping things simple. But I also think we have to understand the nature of institutional entropy. Any system that relies on the active, continuing participation of a particular individual, no matter how well intentioned and no matter how minor, will run off the same cliff. The system has to be inserted directly into the institutional gut. Where the institution goes, it goes. And it needs to be more painful for the institution to remove it, than to leave it in. ARIN meets the criteria of gut wrenching pain. But I wonder how often and how long they can really apply sanctions against a network provider before it becomes easier for the network provider to take some alternative action. So they give ARIN a phone number, get their addresses and disconnect the phone line a week later. In six months or a year, when they need more addresses they plug the phone back in, and call ARIN. I really wish I was just being cynical, but can I see a show of hands of those providers who thought the same thing? Maybe I'm just slow to catch on, but here are what I see the basic principles of an inter-NOC communications system: 1) require an affirmative management action to start participation pay a dollar, cut a ribbon, sign something, do something, anything to avoid the 'NOC cowboy' problem, and everything that engineer did being tainted when he or she leaves. Ok, the CEO doesn't have to understand how it works, she just has to think it was her brillant idea. 2) once in use it should require an affirmative action to disconnect not require anyone to remember to update it. not require anyone to reload the special software on the PC after Microsoft does its periodic self-destruct. neglect shouldn't kill it, only yanking the wires out of the wall or some virtual equivalent should do it in. 3) must not be annoying, but still a pain if it doesn't involve me, don't bother me. the 'normal' channels should be the easiest to use. If you can't show the normal channels failed, you shouldn't be using this. If all else fails, it should get Someone's attention by Klaxon, sirens, flashing lights, you name it. If you answer it, it will shut up. 4) must be a 'visible' system can't be buried on an individual's PC hard drive, or inside a PBX's programming. Even if no one tells them about it, new NOC engineers should trip over it in their normal course of business (i.e. before they need it). "Hey wally, what's that funny machine in the corner for?" 4a) preferably something pointy-haired managers can point to when they are giving tours of the NOC "This is CNN, and this is our inter-NOC communications link" I thought about plugging a EAS-like box into the NOC's CNN feed, since everyone seems to already have CNN in their NOCs. See klaxon, siren, flashing lights above. 5) Positive ID required Everyone (and I mean Everyone) must be able to know exactly who (at least by organizational affiliation) is on, and off the NOC communications net. The list of participants must be able to be published, without fear a non-participant could use the information to intrude into the NOC-net. It should be possible to show the system works to an outsider, without the outsider becoming an insider (i.e. learning the secret handshake). Likewise, it should be possible to positively disprove a non-participant's claim they are on-net if they aren't. No signing MLPA's and never connecting. and I'm a bit leery of #6, but the more I speak with people who give me reasons why they haven't/won't participated in the previous attempts, I can't find a way around it. 6) a STRONG acceptable use policy, and a 'moderator' enforcing it The clash between 'open' and 'private' is a big one. Some folks have said the previous attempts had too much 'noise' and not enough 'signal.' Although from my experience the problem was usually ZERO signal, and ZERO noise. But maybe my filters aren't as sensitive as other peoples'. Since we have not yet created a sucessfull system, all previous attempts going down in the flames of neglect. Who knows if any of those principles are even close to what's required. I hope you noticed most of the my principles involve human or organizational behaivor issues, not technical requirements. I think technically, almost any of the previous systems could have worked. >BTW, I think the line printer idea rules :) In the old days, when I had to walk 20 miles in the snow up hill both ways to school, TYMNET used to send their X.25 outage notifications to customers via Western Union teletype. It wasn't an ASR33, but some type of Telex thermal printer at the time. You knew when it fired up, trouble was on its way. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

route-server.ip.att.net
by Michael Langdon 16 Jul '98

16 Jul '98

Hey... In case you missed the first time amongst all the noise, this router is available with open telnet. Please use it to your debugging contentment. As always, forward questions/comments to me regarding this box. It should be running the latest CE or CC code available. Mike

1 0

Re: Sprint broken bad at MAE-West?
by Donn Lasher 15 Jul '98

15 Jul '98

> 6 sl-bb21-ana-0-3.sprintlink.net (144.232.1.49) 2.843 ms 2.281 ms >3.05 ms > 7 sl-bb10-sj-0-0.sprintlink.net (144.232.8.130) 10.531 ms 11.275 ms >11.891 >ms > 8 sl-bb1-sj-0-0-0.sprintlink.net (144.232.3.2) 11.816 ms 11.561 ms >11.007 m >s > 9 sl-w2-mae-0-1-0.sprintlink.net (144.232.8.10) 1893.24 ms 1759.43 ms >1851. Called Sprint's NOC (Helpful, as always 1-800-232-6895) about 11am PST, and the tech I talked to was monitoring one of the four FDDI connects they have to MAEW. This comment was "Wow, the 5 min traffic for this link(T3) was 71 meg. I think that pipe is a little busy" My comment "Man you guys should get some compression on that line, what a slow T3!" He laughed. (No need for a Tx primer, it was a joke..) Since there was no offical "outage" they haven't informed their customers. I would attribute this to one of two things: 1. One of the pipes died, therefore all traffic is being carried over the other 3(?!) 2. Rush Limbaugh mentioned an interesting web site this morning, and they've been flooded ever since. I'll leave it up to you to figure out which one it is. Donn

1 0