- Test - lists.nanog.org

Re: info
by Paul G. Donner 16 Apr '97

16 Apr '97

At 10:37 PM 4/11/97 -0400, Robert J. Fehn Sr. wrote: >OK, OK, I'm sorry... <G> Can't blame the trend toward less informed personel >on the personel... At least he is seeking out information on his own. Afterall, look at it this way, it takes a lot of guts to ask a basic question on this list. Besides, the sooner we inform him the faster he'll be up to speed. By the the same token, the aquatic thread has been providing some needed refreshment. > > >>> these days? A pulse...? >> >>Come on, I spoke with Tony and explained...give him a break. He's only >>looking for information. >> >>-ron >> >> >> >> > >Robert J. Fehn Sr.,President and CEO >Jersey Cape Information Systems Inc. >609-390-0061 www.jerseycape.net > > > >

2 1

ARIN Discussion from Feb NANOG Notes on line
by sob＠academ.com 16 Apr '97

16 Apr '97

Check http://www.academ.com/nanog/feb1997/ARIN.html. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: MCI outage
by Michael H. Lambert 16 Apr '97

16 Apr '97

>Often most of the major carriers will be using the same set of pipes >across >bridges and railway/highway overpasses. AT&T was advertising their >"redundant path" network where they supposedly made some effort to avoid >this. They were passing out maps and photos of spots with signs from >all the major carriers. > >Power, gas, etc. are often on those same bridges. So if the New Madrid fault were to let loose today with the Big One, how much transcontinental bandwidth would remain? Michael ----- Michael H. Lambert, Pittsburgh Supercomputing Center 4400 Fifth Avenue, Pittsburgh, PA 15213 Phone: +1 412 268-4960 Fax: +1 412 268-8200

1 0

excessive bgp withdraws
by Brett D. Watson 16 Apr '97

16 Apr '97

this might be of interest to some. we found a few weeks ago that we were suddenly on the "bad guys" list at merit, routing-problems(a)merit.edu. we were consistantly making the top ten offenders of "largest sources of bgp instability". we had upgraded to a new version of code in our peer router in san jose that had "lost" the fix to bgp to stop these excessive withdraws which had been discussed on nanog some time ago. we got a new image with the fix rolled back in 2 days ago and will be deploying soon. i don't know what version everyone is running but if you're making this list consistantly you might check with your vendor to see if your version of code is lacking this fix. here is yesterday's list for those that don't subscribe to routing-problems: Largest Sources of BGP Instability ---------------------------------- (announcements + withdraws = total) 1. ANS (AS1673) at Mae-East 7124 + 276413 = 283537 BGP prefix updates 2. INSnetUSA (AS6660) at Mae-East 11 + 250384 = 250395 BGP prefix updates 3. SPRINT (AS1239) at Mae-East 170072 + 69258 = 239330 BGP prefix updates 4. HLCnet (AS4565) at Mae-West 14 + 229402 = 229416 BGP prefix updates 5. GRIDNET (AS6113) at Mae-East 647 + 220572 = 221219 BGP prefix updates 6. GRIDNET (AS6113) at PacBell 646 + 195514 = 196160 BGP prefix updates 7. GRIDNET (AS6113) at Mae-West 640 + 193955 = 194595 BGP prefix updates 8. IconNet (AS3951) at Mae-East 36 + 190158 = 190194 BGP prefix updates 9. ANS (AS1673) at Mae-West 7757 + 174053 = 181810 BGP prefix updates 10. Genuity (AS3847) at Mae-West 1144 + 165556 = 166700 BGP prefix updates -brett

1 0

Sprint Filters - what are they?
by Gregory Hersh 16 Apr '97

16 Apr '97

A while ago we had a customer with some routing problems which were caused by Sprint filters (127/8 - 191/8, deny anything longer than /16). When customer called Sprint, he's been told by someone from tech support that 'Sprint doesn't filter anything'. When I called support, I've been told that on 127/8 - 191/8 range Sprint denies anything longer than /16. This morning the same customer called Sprint again, to confirm this information, and been told that for the above range Sprint denies anything longer than /19. It seems like each time you call Sprint support, you hear a different story. Will someone from Sprint _who knows_ confirm their filtering policy which I have as follows: 0/8 - 126/8, deny subnets of historical A's 127/8 - 191/8, deny anything longer than /16 192/8 - 205/8, deny anything longer than /24 206/8 - 223/8, dney anything longer than /19 192/8 [RIPE], deny anything longer than /19 It would be really nice to have it posted at NANOG web page as well (alas, only AGIS done so). Thanks, - Greg -

2 1

Outage (planned and unplanned) notification
by Sean Donelan 15 Apr '97

15 Apr '97

>Got off the phone w/Hector @MCI indicating that they are currently have >problems with their OC12 ckt in Illinois. Routing through their network >is getting beat up... I've noticed the sprint outage list has become very quiet, as has the MCI outage list. They seem to be quiet even during and after widely known problems. The same is true of most providers I bother to track. Even those providers I have signed agreements which include notification requirements. Since I still notice end-to-end interruptions of service, I don't think the network has really become as reliable as the lack of outage notifications might indicate. Are folks just not bothering to keep everyone informed? Should I go back to nagging your NOC folks with phone calls? Perhaps its just different expectations. For example, I don't bother to notify people about MAE-West outages that effect everyone because I assume the operator of MAE-West should handle that, and a NxN set of providers notifying each other isn't helpful. And a lot of the time extraneous notifications just muck up the trouble ticket system. Is there anything that will encourage pro-active notification? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

5 4

Re: Eating My Collapse Column
by fehnb＠jerseycape.net 15 Apr '97

15 Apr '97

>Internet still needs much more cooperation among ISPs on managing its >operations, and perhaps we'll see some soon. Which is to say that, >despite eating my column, I stand by my story. > The spirit of you prediction lives on even if the fact has passed us by.... Robert J. Fehn Sr.,President and CEO Jersey Cape Information Systems Inc.

1 0

Eating My Collapse Column
by Bob Metcalfe 15 Apr '97

15 Apr '97

Dear NANOG, You've perhaps already heard that I made good on a promise to eat the 12/4/95 InfoWorld column in which I predicted Internet collapses during 1996. If not yet, then please. Yes, eating the column was a publicity thing, of course, and look at all the publicity it got. As widely reported, I ate the entire column out of a bowl with a spoon before an appreciative live audience of about 1,000 people attending my terminal keynote at the Sixth International World Wide Web Conference in Santa Clara, California. Some reports skipped that I ate (and am still digesting) the entire column. I did. Rest assured. So, sorry to those of you who could not be there to witness my comeuppance. And sorry to those of you whom I over excited during 1996 by warning of Internet outages and arguing for more organized cooperation (than NANOG) among ISPs in managing Internet operations. Of course you should understand that I ate the column only because the Internet, as far as I can tell, did not suffer a gigalapse during 1996 -- a billion lost user*hours in a single outage. The Internet has indeed bogged down (hit STOP much?) and has indeed suffered large outages (the biggest being a 118 megalapse at AOL in August). The Internet still needs much more cooperation among ISPs on managing its operations, and perhaps we'll see some soon. Which is to say that, despite eating my column, I stand by my story. But, again, I was wrong -- we were lucky -- about the 1996 gigalapse. Again, I was wrong. I ate the column. I am sorry. I am not worthy. Now, be thinking about what you're going to eat (;->) if we don't get our Internet operations acts together in time to avert gigalapses. Lovingly on your case, /Bob Metcalfe, InfoWorld columnist

9 8

Re: MCI outage
by Russ Haynal 14 Apr '97

14 Apr '97

At 04:53 PM 4/12/97 -0700, Michael Dillon wrote: >On Sat, 12 Apr 1997, Russ Haynal wrote: > >> As an ISP, BBN may be peering with MCI(the ISP), but I too had the >> Understanding that Some of BBN's fiber was leased from MCI(the telco?). >> Anyone else with insight ? > >I think the day is long gone when any meaningful insight can be gained by >looking at this kind of thing. It is entirely possible that SprintLink is >leasing MCI T3's and InternetMCI is leasing Sprint T3's and that both of >the T3's are running in the same fibre bundle owned by Worldcom. > >The three layers, IP services, digital data service, and dark fiber, are >getting rather intertwingled and this doesn't even take into account usage >of frame networks or ATM networks. I'm not implying anything specific >by naming the three companies above, just that it is not very easy to find >out where a particular IP provider gets their service and it is hard to >extrapolate anything useful from that information if you did know it. This brings up another point I've pondered... I've noticed that many of the Backbone ISP backbone maps seem to have an amazing amount of similarity - i.e. connections between identicle sets of cities. I wonder how many different ISP's might be riding within the same Fiber bundle (the one right below some guy's back-hoe) If BBN and Internet MCI both run inside of MCI's fiber to/from a small ISP's hometown, then it won't make much sense for a small ISP to get a T-1 from MCI and BBN in the name of "redundancy" - If they both can be taken out with one backhoe. Might this risk still exist if my UUNET/Worldcom fiber also happens to lay 2 feet away from MCI's fiber in the ground in some kind of "telco right of way" Russ __________________________________________________________________ Russ Haynal - Internet Consultant, Instructor, Speaker "Helping organizations gain the most benefit from the Internet" russ(a)navigators.com http://www.navigators.com 703-729-1757 ------------------------------------------------------------------ Author:"Internet; A Knowledge Odyssey" (Top-rated CD-ROM Tutorial) Available from MindQ Publishing: http://www.mindq.com

3 2

Re: Outage (planned and unplanned) notification
by Joe Provo - Network Architect 14 Apr '97

14 Apr '97

[snip] >> I've noticed the sprint outage list has become very quiet, as has the >> MCI outage list. They seem to be quiet even during and after widely [snip] Sprint's list has gotten better regarding notifications. Using existing customer-provider relations is very useful. For our providers that are lax in notification, we hit the mangvlement/customer relations/sales folk pretty hard. In a collaborative enviornment, non-customers having a problem with provider S could contact a customer of provider S and have them source the trouble call [this is not, purely hytpothetical]. >I'm thinking that it might be useful about now to set up a decent >notification organization that can seek out network status and outage [snip] As was pointed out elsewhere, the NLARN IPNmoo has been up and running for quite some time. The others in the handful that would be considered 'regulars' may want to comment as well, but I for one find it of great value. We've seen several instances of real-time debugging w/in this collaborative environment. Cheers, -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

2 1