June 1997 - NANOG - lists.nanog.org

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

DOMAIN STEALING?
by Vir Lagua 25 Jun '97

25 Jun '97

What is your intention for submitting the modification template below? Please reply to this message to confirm that the following update request should be completed. Enter A or ACK in item 0a if you agree. Enter N or NAK in item 0a if you disagree. The request that was submitted has been appended to this email message for your review. ***************** Please DO NOT REMOVE Version Number ***************** Notify Version Number: 1.0 ************** Please see attached detailed instructions ************** 0a. (A)ck (N)ak.....: NAK 0b. Comments........: Submitted (0845062597MDT) - hostmaster(a)slip.com Object 1a. Identifier......: SLIP-DOM 1b. Type............: D 1c. Tracking Number.: 970624.11974 1d. Message ID......: 199706241952.MAA02835(a)repairnet.com 1e. Notify..........: BEFORE-UPDATE 1f. Comments........: Update to a domain record must be submitted by the current administrative or technical contact of the domain. Both contacts have been notified of this update request. If either contact replies to the message sent and acknowledges that the request should be completed, the update will be processed. If you are a technical or administrative contact for this domain and you are still getting this message maybe your auth info is not current. And if your auth info is not current, update it using contact template. email hostmaster(a)internic.net voice (703) 742-4777 ========================================================================= y.a.c.c. (SLIP-DOM) 1253 TURQUOISE SANDY, UT 84094-4006 US Domain Name: SLIP.COM Administrative Contact: Lagua, Vir (VL6) hostmaster(a)SLIP.COM 1.801.329.6366 Technical Contact: Lagua, Vir (VL6) hostmaster(a)SLIP.COM 1.801.329.6366 Billing Contact: Lagua, Vir (VL6) hostmaster(a)SLIP.COM 1.801.329.6366 Record last updated on 03-Sep-96. Record created on 20-Apr-94. Domain servers in listed order: NS1.UTAH-NET.NET 206.26.69.35 NS.SLIP.COM 199.165.251.2 ========================================================================= > From donv(a)repairnet.com Tue Jun 24 15:57:06 1997 > Received: from rs2.internic.net (rs2.internic.net [198.41.0.7]) by opsmail.internic.net (8.8.5/8.8.0) with SMTP id PAA06131 for <hostmaster@int ernic.net>; Tue, 24 Jun 1997 15:57:04 -0400 (EDT) > Received: (qmail 13497 invoked from network); 24 Jun 1997 19:56:48 -0000 > Received: from repairnet.fresno.qnis.net (HELO repairnet.com) (root(a)206.171.190.77) > by rs2.internic.net with SMTP; 24 Jun 1997 19:56:48 -0000 > Received: (from root@localhost) by repairnet.com (8.8.2/8.6.9) id MAA02835 for hostmaster(a)internic.net; Tue, 24 Jun 1997 12:52:01 -0700 > Date: Tue, 24 Jun 1997 12:52:01 -0700 > From: Don VonderBurg <donv(a)repairnet.com> > Message-Id: <199706241952.MAA02835(a)repairnet.com> > Subject: [NIC-970624.11974] Your Mail > X-MTS-Ticket: 970624.11974 > X-MTS-Type: Domain > X-MTS-Mode: Unknown > X-MTS-Priority: Normal > X-MTS-Status: Open > X-MTS-Timestamp: 970624155730 > > > [ URL ftp://rs.internic.net/templates/domain-template.txt ] [ 6/97 ] > > **************** Please DO NOT REMOVE Version Number *************** > > Domain Version Number: 3.5 > > 0a. (N)ew (M)odify (D)elete.........:M > 0b. Auth Scheme.....................: > 0c. Auth Info.......................: > > 1. Purpose/Description.............: > > 2. Complete Domain Name.............:slip.com > > Organization Using Domain Name > 3a. Organization Name (Registrant)..: > 3b. Street Address..................: > 3c. City............................: > 3d. State...........................: > 3e. Postal Code.....................: > 3f. Country Code (2 letter).........: > > Administrative Contact/Agent > 4a. NIC Handle (if known)...........:DV268 > 4b. (I)ndividual or (R)ole?.........:I > 4c. Name............................: > 4d. Organization Name...............: > 4e. Street Address..................: > 4f. City............................: > 4g. State...........................: > 4h. Postal Code.....................: > 4i. Country Code (2 letter).........: > 4j. Phone Number....................: > 4k. Fax Number......................: > 4l. Email Address...................: > > Technical Contact > 5a. NIC Handle (if known)...........:DV268 > 5b. (I)ndividual or (R)ole?.........:I > 5c. Name............................: > 5d. Organization Name...............: > 5e. Street Address..................: > 5f. City............................: > 5g. State...........................: > 5h. Postal Code.....................: > 5i. Country Code (2 letter).........: > 5j. Phone Number....................: > 5k. Fax Number......................: > 5l. Email Address...................: > > Billing Contact > 6a. NIC Handle (if known)...........:CV236 > 6b. (I)ndividual or (R)ole?.........:I > 6c. Name............................: > 6d. Organization Name...............: > 6e. Street Address..................: > 6f. City............................: > 6g. State...........................: > 6h. Postal Code.....................: > 6i. Country Code (2 letter).........: > 6j. Phone Number....................: > 6k. Fax Number......................: > 6l. Email Address...................: > > Primary Name Server > 7a. Primary Server Hostname.........:ns.repairnet.com > 7b. Primary Server Netaddress.......:209.77.228.1 > > Secondary Name Server(s) > 8a. Secondary Server Hostname.......:ns.qnis.net > 8b. Secondary Server Netaddress.....:206.171.190.2

2 1

Re: Network IP analysis?
by jprovo＠ma.ultranet.com 25 Jun '97

25 Jun '97

[snip] >using MRTG. Are there any other viable alternatives to MRTG, or are >there any existing mods to mrtg that graph right out of a file rather >than polling for itself? I already have the data I need and would MRTG happily graphs arbitrary 3external programs, etc. You just have to hand the data to mrtg in a matter that it likes. Take a trip to the mailing list archive; it's worth it. Cheers, -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0