- Test - lists.nanog.org

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

Re: PSI woes
by dlr＠bungi.com 25 Jun '97

25 Jun '97

[In the message entitled "Re: PSI woes" on Jun 25, 7:33, Robert Bowman writes:] > Looks like Dave has already prepended.. I'll bet PSI is LPing the PX > link over IXP peers, if the path exists on both.. which basically > has made all of Dave's attempts futile (meds, prepends, inconsisent, > etc) > > rob Correct. That's the conclusion that I came to. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

PSI woes
by dlr＠bungi.com 25 Jun '97

25 Jun '97

Is anyone else having routing problems with PSI? On the left coast, we peer with PSI. We buy transit from MCI. PSI recently (about a month ago) installed a broken localpref to prefer their private MCI connection. It doesn't matter what we advertise to MCI (double-hop, origin incomplete), PSI still uses their private MCI peering - which of course is full during the day, so PSI customers get packet loss. Naturally, the problem does not exist on the right coast :-) I've called the NOC about 20 times now, trying to get it resolved. I've been promised, multiple times, that it would be fixed, only to get told today that "it's a policy issue". What? :-( Anyone else having trouble? -- Dave Rand dlr(a)bungi.com http://www.bungi.com

3 2

Re: Network IP analysis?
by Tobias Oetiker 25 Jun '97

25 Jun '97

> Date: Wed, 25 Jun 1997 07:39:09 -0500 (CDT) > From: Tim Peiffer <peiffer(a)nts.umn.edu> > To: philip bridge <bridge(a)unisource.ch> > Cc: nanog(a)merit.edu > Subject: Re: Network IP analysis? > > MRTG is a great graphing tool for small applications. Unfortunately > the package does not scale very well for my purposes. The snmp polling > and data storage in the logfiles are areas that I have problems with > 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 > like to reuse it. If possible I would like to have a package that > is separated into 3 sections. One section can be called upon to > do polling or gathering data out of a repository. The second can > be called upon to do statistics runs. The 3rd can be called to provide > graphs on demand. if you have the time and interest, you are welcome to help bringing mrtg-3.0 into the real world ... all the plans for it are here, but unfortunately progress is slow because of resource problems (time or money) The main features planned for mrtg 3.0: * Ultra Fast Logfile Handling * Modular desing with separate processes for data gathering data logging and data presentation ... I have written a paper about what is intended. Check http://www.ee.ethz.ch/~oetiker/webtools/mrtg/3.0 If you have comments, time or money to help getting it done, please let me know ... cheers tobi (Mr. MRTG) -- ______ __ _ /_ __/_ / / (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich / // _ \/ _ \/ / TEL:+41(0)1-6325286 FAX:+41(0)1-6321194 /_/ \___/_.__/_/ oetiker(a)ee.ethz.ch http://www.ee.ethz.ch/~oetiker

1 0