- Test - lists.nanog.org

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

Re: PacBell
by Brett D. Watson 25 Jun '97

25 Jun '97

> > I can think of one good reason: > > Not everyone you might want to peer with on the West Coast > is at the PAIX. that brings up another question i've meant to ask. what are the larger provider's reasons (if anyone cares to comment) for not peering at paix? mci? sprint? is it just the typical feeling that more public peering is not necessarily a good thing, or something else? -brett

2 1

Sprint?
by Alex Rubenstein 25 Jun '97

25 Jun '97

I was wondering if Sprint had any intention to fix thier hostnames on thier routers. Ever since upgrading the recent versions of Os's, the name resolveres no longer resolve names with '/'s in them. Ie: on a cisco: 1 nac-nyc1-s0-3Mb.nac.net (207.99.7.14) 4 msec 4 msec 16 msec 2 e9-0.border1.nyc1.genuity.net (207.240.48.49) [AS 3847] 12 msec 4 msec 3 f6.core1.nyc1.genuity.net (207.240.1.81) [AS 3847] 12 msec 12 msec 8 4 peer1.nyc1.genuity.net (207.240.48.3) [AS 3847] 16 msec 16 msec 56 5 sl-pen-2-F4/0.sprintlink.net (192.157.69.10) [AS 3561] 132 msec 212 6 sl-pen-20-F1/0-100M.sprintlink.net (144.232.0.121) [AS 1239] 20 msec 7 sl-pen-17-P4/0/0-155M.sprintlink.net (144.232.0.65) [AS 1239] 16 msec yet, on freeBsd 2.2: traceroute to www.visi.com (204.73.178.2), 30 hops max, 40 byte packets 1 nac-whi4-Fa0-100Mb (207.99.5.204) 0.989 ms 2.527 ms 0.840 ms 2 nac-nyc1-s0-3Mb (207.99.7.14) 23.137 ms 22.779 ms 12.263 ms 3 e9-0.border1.nyc1.genuity.net (207.240.48.49) 38.895 ms 14.305 ms 4 f6.core1.nyc1.genuity.net (207.240.1.81) 12.118 ms 9.193 ms 10.028 5 peer1.nyc1.genuity.net (207.240.48.3) 24.715 ms 23.773 ms 16.742 ms 6 192.157.69.10 (192.157.69.10) 20.605 ms 27.076 ms 18.037 ms 7 144.232.0.121 (144.232.0.121) 20.211 ms 28.754 ms 10.973 ms 8 144.232.0.65 (144.232.0.65) 10.669 ms 17.250 ms 23.139 ms Hrmph.

4 3

more routes than normal
by Andrew Bangs 25 Jun '97

25 Jun '97

Sorry for waking you all before breakfast, but is anyone else seeing ~5000 more routes than normal this morning ? Just a sample of some unusually long ASPaths I'm seeing here Jun 11 10:03:41 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 1323 1323 1323 1323 1323 1323 1673 1239 1792 2907 2498 Jun 11 10:03:41 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 5646 1793 1239 3561 4574 Jun 11 10:05:45 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 1323 1323 1323 1323 1323 1323 1673 3561 577 549 Jun 11 09:57:59 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 1323 1323 1323 1323 1323 1323 1673 5378 5459 (and it isn't just PSI we're seeing these from, just that that was the log I looked in. 2041 3789 seems a common factor though. ) GateD-beech.router.demon.net> show ip routes 100 IP radix tree: 97679 nodes, 50773 routes GateD-beech.router.demon.net> This is looking horribly familiar. Regards, Andrew -- Andrew Bangs, Senior Systems Administrator, Demon Internet Ltd andrewb(a)demon.net http://www.demon.net/ http://www.demon.nl/

11 12

Re: DOMAIN STEALING?
by Vir Lagua 25 Jun '97

25 Jun '97

To NANOG readership; SORRY about this posting... Clicked the wrong address > >What is your intention for copying this garbage to NANOG? > >

1 0