- NANOG - lists.nanog.org

OFF TOPIC: Looking for GNU Make Binary for Solaris x86
by Matthew Pearson 26 Jun '97

26 Jun '97

I am searching for a binary for GNU Make (3.75 perferred) for Solaris 2.5.1 on Intel x86 If anyone has such a beast, please email me and save my sanity (and hours of scouring the web) M

1 0

Lots of non-existant networks
by Eric D. Madison 26 Jun '97

26 Jun '97

There still seems to be a lot of Routes out there that are not in the RADB. I know that ANS is not excepting routes not in a routing database, and others are starting to follow. It's a good idea! I am not getting some of these routes because of the lack of an RADB entry, and it's very frustrating.. Anyone else having the same problems?? Ohh one more thing.. Seems that there are also some routes that are being advertised that don't even have a InterNIC/RIPE/APNIC entry either.. If they don't have an entry, then they are not real "Valid" routes, so I don't want to route them.. but the Origin is from a large provider.. any suggestions? Seems that they have build their whole infrastructure on these routes too. Eric _______________________________________________________ Eric D. Madison - Senior Network Engineer - ACSI - Advanced Data Services - ATM/IP Backbone Group 24 Hour NMC/NOC (800)291-7889 Email: noc(a)acsi.net

6 5

Aol.com missing ??
by Eugene Mondrus 26 Jun '97

26 Jun '97

I am pointing to the UUNET DNS servers, and I am getting "Bad IP Address" for a bunch of domains: aol.com netscape.com erols.com etc .... It is also affecting a few other DNS servers not belonging to UUNET. Any suggestions ??? Gene Mondrus Webmaster Bigfoot.com

3 2

Aol.com missing ??
by Eugene Mondrus 26 Jun '97

26 Jun '97

Whoops, sorry I'm a _Dunce_ . My DNS servers were acting up, and I didn't check it right. Sorry Thanks Gene

1 0

PacBell
by J.D. Falk 26 Jun '97

26 Jun '97

Well, due to the lack of traffic, here's a question that I've been pondering...are there any good reasons (besides MCI's peering requirements) to go into the Pac Bell NAP as well as MAE-West and the PAIX? (This question probably won't have any impact on any decisions; I'm just curious as to people's thoughts on the matter, and it's nice to be able to post something here that isn't about net abuse.) *********************************************************************** J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ***********************************************************************

7 8

Domain Name Registration Agreement v3.5
by Tom Newell 26 Jun '97

26 Jun '97

6/23/97 Version 3.5 of the Domain Name Registration Agreement has been released. Network Solutions (InterNIC) will accept registrations submitted using either Version 3.0 or Version 3.5 through July 23, 1997. The changes incorporated into Version 3.5 are: 1. Clarification of the terms and conditions of the Domain Name Registration Agreement; 2. Deletion of Section 9 (Invoice Delivery option) from the form since the billing contact is now automatically invoiced by both postal mail and email; 3. Improved instructions. Version 3.5 is available in text format and has also been incorporated into the step-by-step and single page Web-based forms. Associated URL's: ftp://rs.internic.net/templates/domain-template.txt http://rs.internic.net/cgi-bin/itts http://rs.internic.net/cgi-bin/domain Regards, --Tom --------- Tom Newell tomn(a)internic.net Dir, Info Svcs & Tech +1 703 742 4796 Network Solutions, Inc http://www.netsol.com http://rs.internic.net

1 0

Re: Network IP analysis?
by philip bridge 26 Jun '97

26 Jun '97

At 01:17 25.06.97 -0400, Martin J. Hannigan wrote: >I just recently snagged MRTG, a freeware SMNP package that will poll a router >allowing snmp access. It seems like a simple traffic monitoring/averaging/history >program that is too simple to use, but provides easy to understand information >in a visual context. Cisco's are really easy to configure for snmp polling >by MRTG. > >I'm sorry I can't post the ftp sites. Can't think of them off the top >of my head and too late to search. Apologies. Maybe someone else knows >firsthand? > MRTG is a great tool that we use a lot - especially good if you want to offer traffic monitoring to customers. MRTG can get the stats from the customers port and display that as a GIF on your web server, accessed using the customers ID and password. Stops all those calls from customers asking if their access lines are overloaded... It is mostly used for traffic monitoring, but can work with any SNMP variable. In the latest release it can monitor/display round trip delays as well. The URL is http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html Netflow has also been mentioned on this thread. The drawback is that Netflow only works on cisco 72xx and 75xx platforms. Phil

4 3

RE: Network IP analysis?
by Dan Dale 26 Jun '97

26 Jun '97

Don't know if you've seen this link. Might be a nice addition to your tool chest. http://www.nlanr.net/Caidants/meastools.html Followed it from Russ Haynal's ISP Page. http://navigators.com/isp.html Regards, Dan -----Original Message----- From: Bruce Potter [SMTP:gdead@alaska.net] Sent: Tuesday, June 24, 1997 9:49 PM To: nanog(a)merit.edu Subject: Network IP analysis? Howdy, Does anyone know of any good IP monitoring tools that can log/monitor the TYPES of IP traffic going across your netowork (ie: one that logs tcp/udp and esp port numbers/types of traffic)? Something that could query a router would be nice, although I am unaware of any routers that support such a feature. Even something that you could put on a box on the same ethernet subnet would do the job. I'm curious as to the types of traffic our customers are pushing as I am attempting to better analyze our usage. Thanks. ----------------------------------------------------------------- Bruce Potter Internet Alaska, Inc. gdead(a)alaska.net Grateful Admin InterNIC Handle: BGP4 ;-) PGP Public Key: http://www.alaska.net/~gdead/gdead.asc Key ID: 1024/F12AC0B1 -----------------------------------------------------------------

1 0

MCI outages (summary)
by William Allen Simpson 26 Jun '97

26 Jun '97

>From: "Jeff Young" <young(a)mci.net> >gee bill, bucking for your own column in boardwatch again? I'm afraid that I have no idea what you are talking about. To the best of my knowledge, I've never been offered a column in boardwatch. Of course, I've been paid to write articles for a number of magazines over the years. >our noc still does an exemplary job, thanks. To summarize private reports, MCI NOC lost a fair number of its top technical staff when they "consolidated" their customer oriented NOCs into a single unit last year. Now, the folks answering the phone aren't well trained in Internet; instead they are telco oriented. I noticed that, too. > ... we don't do >maintenance in the middle of a sunday afternoon, unless of >course, you were in australia at the time. > That explains why it took half a day to fix your routing problem. Maintenance shift must come on duty around 10 pm EDT, eh? And, of course, you've seen the note that you had a router down in Houston at about those times. Must be official policy not to "admit" outages. >you've been around long enough to know the drill, you call >your upstream, he calls his, etc., etc., Actually, the "drill" is as follows: 1) makes sure it's not a problem with my upstream, that is singly homed to MCI. It wasn't. 2) since my upstream is singly homed, they have no interest in solving MCI routing problems, and refer all such calls to the MCI NOC. 3) in this case, since the other site was known to me, call them and see if they are experiencing a problem. Yes, they were having some problems with MCI, too. They are also singly homed. 4) traceroutes clearly showed that it was an MCI problem. 5) call MCI NOC with information. 6) get shrugged off with a recommendation that I send my problem to trouble(a)mci.com. This would be amazing if it were not so incredibly stupid, since it was my inability to get my email that brought the problem to my attention. >you expect our >front line noc to know you by name? Goodness gracious, while that personal touch can be pleasant, it is not required. But, I do expect them to have an idea what the IP addresses of their own routers are, and not have to go on hold to find out about traceroutes.... > From: Sean Donelan <SEAN(a)SDG.DRA.COM> > If you've been around long enough, you remember the days when > the MCI NOC used to flat-out refuse to do inter-provider referals. > .From first-hand experience, I know they've told their customers to > call the other provider directly, even when both networks involved > were direct MCI customers. In my experience, most smaller NOCs refuse to do inter-provider referrals these days. Too many levels. > But I have accumulated a large collection of 1-800 > numbers that I can use to call people I know by name :-). I prefer > to go through channels, but when the channels don't work, I'm just > as comfortable using any means necessary. > Same here. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: PSI woes
by William Allen Simpson 26 Jun '97

26 Jun '97

> From: dlr(a)bungi.com (Dave Rand) > Is anyone else having routing problems with PSI? > I don't talk directly to PSI, but Morningstar/Ascend does, and I see the peering between MCI and PSI drop for hours on a regular basis. I find that the "host unreachable" comes from either #5 or #7 below: 5: 192.203.195.5 cpe3-fddi-1.WillowSprings.mci.net. (109 ms) (109 ms) (107 ms) 6: 166.48.23.253 bordercore2-hssi1-0.WillowSprings.mci.net. (190 ms) (136 ms) (134 ms) 7: 204.70.4.9 core3.Atlanta.mci.net. (420 ms) (501 ms) (418 ms) 8: 206.157.77.50 ast-psi-nap.Atlanta.mci.net. (199 ms) (208 ms) (301 ms) 9: 38.1.2.5 se2.sc.psi.net. (160 ms) (169 ms) (219 ms) I'm not sure where the problem actually occurs, as WillowSprings is rather congested, with rather variable transit times. Apparently, all the MCI-PSI routing for the heartland (I'm in Michigan, M-Star is in Ohio) goes through Atlanta, and there is no backup exchange that I've seen recently (it used to be at Cornell). I suppose this is an improvement, the path used to go Chicago, Cleveland, Boston, NewYork, MAE-East on MCI, and back to Detroit on PSI, before Columbus. Neither MCI nor PSI seem to be big on regional peering at multiple points with failover.... Sure would be nice to put the "net" back in Internet. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0