- Test - lists.nanog.org

NANOG REGISTRATION
by lnguyen＠sprint.net 19 Apr '95

19 Apr '95

REGISTRATION FORM NANOG - MAY 22 & 23, 1995 NANE:____LAN NGUYEN________________________________________ ORGANIZATION:______SPRINT__________________________________________________ E-MAIL:_____LNGUYEN@SPRINT.NET______________________________________________ ___________ ATTENDANCE: MONDAY______X___ TUESDAY_____X_____ LUNCH: __________YES ___X________NO $10.00 SELECTION: ____________VEGGIE ____________ROAST BEEF _________TURKEY __________CORNED BEEF _____________TUNA ===============================================================================

1 0

Re: Has PSI been assigned network 1?
by Martin L. Schoffstall 19 Apr '95

19 Apr '95

there are about a dozen ISP's extensively using ascend's which have this hole. our original RFP to them dealt with this issue but they did not execute they keep trying to fix this, but so far no go we have tried to keep this quiet so that microsoft/uunet/psinet/etc..... don't get extensively hacked we have had two occurences of this so far in one year that I know of though there are probably more marty > PSI allows people to negotiate PPP addresses, and then > propagates everything everywhere w/o even token filtering. I.e. any > idiot can subscribe to PSI service and kill the Internet. > > --vadim > > Date: Sun, 16 Apr 95 21:02:04 MET DST > >From: Peter Lothberg <roll(a)Stupi.SE> > To: schoff(a)psi.com, nanog(a)merit.edu, postel(a)isi.edu Subject: Has PSI > been assigned network 1? > > Or why are they announcing it to the rest of the Internet through > their box at MAE-East??? > > bash$ whois 1.0.0.0 > No match for "1.0.0.0". > > The InterNIC Registration Services Host contains ONLY Internet > Information (Networks, ASN's, Domains, and POC's). > Please use the whois server at nic.ddn.mil for MILNET Information. > > > traceroute 1.1.1.1 > traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 40 byte packets > 1 sl-dialup-2.sprintlink.net (192.157.36.128) 252 ms 245 ms 223 > ms 2 192.157.36.1 (192.157.36.1) 251 ms 250 ms 251 ms 3 sl-dc-1- > S3-T1.sprintlink.net (144.228.0.225) 252 ms 262 ms 253 ms 4 > icm-dc-1-F0/0.icp.net (144.228.20.101) 275 ms 269 ms 252 > ms 5 psi-mae-east-1.psi.net (192.41.177.235) 268 ms 254 ms 241 > ms 6 washington2.dc.isdn.psi.net (38.146.99.110) 261 ms 271 ms 262 > ms 7 1.1.1.1 (1.1.1.1) 457 ms 1284 ms 543 ms > > bash$ traceroute 1.1.1.2 > traceroute to 1.1.1.2 (1.1.1.2), 30 hops max, 40 byte packets > 1 sl-dialup-2.sprintlink.net (192.157.36.128) 253 ms 253 ms 246 > ms 2 192.157.36.1 (192.157.36.1) 246 ms 243 ms 228 ms 3 sl-dc-1- > S3-T1.sprintlink.net (144.228.0.225) 249 ms 447 ms 313 ms 4 > icm-dc-1-F0/0.icp.net (144.228.20.101) 274 ms 251 ms 278 > ms 5 psi-mae-east-1.psi.net (192.41.177.235) 265 ms 257 ms 266 > ms 6 core.net228.psi.net (38.1.2.7) 286 ms 278 ms 276 > ms 7 core.net99.psi.net (38.1.2.10) 338 ms 370 ms 279 > ms 8 core.net228.psi.net (38.1.2.7) 306 ms 326 ms 290 > ms 9 core.net99.psi.net (38.1.2.10) 335 ms 308 ms 325 ms > 10 core.net228.psi.net (38.1.2.7) 372 ms 353 ms 341 ms 11 > core.net99.psi.net (38.1.2.10) 376 ms 385 ms 377 ms 12 > core.net228.psi.net (38.1.2.7) 438 ms 375 ms 365 ms 13 > core.net99.psi.net (38.1.2.10) 384 ms 441 ms 371 ms 14 > core.net228.psi.net (38.1.2.7) 394 ms 426 ms 474 ms 15 > core.net99.psi.net (38.1.2.10) 427 ms 540 ms 565 ms 16 > core.net228.psi.net (38.1.2.7) 521 ms 500 ms 489 ms 17 > core.net99.psi.net (38.1.2.10) 530 ms 483 ms 527 ms 18 > core.net228.psi.net (38.1.2.7) 567 ms 493 ms 561 ms 19 > core.net99.psi.net (38.1.2.10) 779 ms 462 ms 670 ms 20 > core.net228.psi.net (38.1.2.7) 531 ms 620 ms 613 ms 21 > core.net99.psi.net (38.1.2.10) 562 ms 728 ms 598 ms 22 > core.net228.psi.net (38.1.2.7) 812 ms 566 ms 835 ms 23 > core.net99.psi.net (38.1.2.10) 661 ms 678 ms 574 ms 24 > core.net228.psi.net (38.1.2.7) 647 ms 820 ms 666 ms 25 > core.net99.psi.net (38.1.2.10) 649 ms 625 ms 628 ms 26 > core.net228.psi.net (38.1.2.7) 900 ms 634 ms 733 ms 27 > core.net99.psi.net (38.1.2.10) 648 ms 659 ms 656 ms 28 > core.net228.psi.net (38.1.2.7) 776 ms 979 ms 834 ms 29 > core.net99.psi.net (38.1.2.10) 715 ms 689 ms 734 ms 30 > core.net228.psi.net (38.1.2.7) 782 ms 785 ms 677 ms > > > ---Peter > >

6 10

Re: Has PSI been assigned network 1?
by Guy Middleton 19 Apr '95

19 Apr '95

> Curtis, you are able to do that only because all others were > legally bound to fill your database. > > I'm not sure people will be spending their resources on > populating database for somebody else's benefit. > > (And RADB already has lots of garbadge in it). Once the RADB is in general use, we can expect that networks other than ANS will use it to generate route-filters. There is an interconnect point already using the CA*net registry, for example. Any active use of the RADB creates an incentive to ensure that it is accurate.

1 0

Re: Final transition steps
by rrv＠uiuc.edu 18 Apr '95

18 Apr '95

At 12:08 PM 4/18/95, Elise Gerich wrote: >129 NCSA networkMCI > CICnet networkMCI > MSC Sprintlink > UIRnet CICnet > UIUC networkMCI 129 NCSA CICnet CICnet networkMCI MSC Sprintlink UIRnet CICnet UIUC CICnet

2 1

Re: Has PSI been assigned network 1?
by sob＠academ.com 18 Apr '95

18 Apr '95

prs-request(a)isi.edu appears to be a non-functional address. On Apr 18, 6:39pm, Mail Delivery Subsystem wrote: } Subject: Returned mail: User unknown } This is a MIME-encapsulated message } } --SAA01554.798248343/owlman.academ.com } } The original message was received at Tue, 18 Apr 1995 18:39:02 -0500 } from sob@localhost } } ----- The following addresses had delivery problems ----- } prs-request(a)isi.edu (unrecoverable error) } } ----- Transcript of session follows ----- } ... while talking to isi.edu.: } >>> RCPT To:<prs-request(a)isi.edu> } <<< 550 <prs-request(a)isi.edu>... User unknown } 550 prs-request(a)isi.edu... User unknown } } ----- Original message surpressed ----- } }-- End of excerpt from Mail Delivery Subsystem -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Final transition steps
by Elise Gerich 18 Apr '95

18 Apr '95

We are approaching the last weeks of the NSFNET Backbone Service. Despite good intentions, only seven (7) organizations have completely severed their relationship with the NSFNET Backbone service. Those seven (7) are: Argonne National Laboratory CA*net Cornell Supercomputer Center DARPA Michnet NYSERnet SURAnet Many other organizations depend on a new service provider and they continue to maintain the NSFNET connectivity for backup purposes. Merit has encouraged organizations who maintain redundant connectivity to voluntarily discontinue connectivity to the NSFNET service in advance of April 30,1995. The reason prompting this request is that it is difficult to identify outstanding reachability issues as long as there are still dependencies on the NSFNET Backbone service. If an organization can confirm reachability to all destinations that are currently reachable, the chances for an uneventful changing of the guard on April 30 increase. To this aim, Merit is encouraging all organizations which will lose direct access to AS 690 on April 30, 1995 to decommission their peering sessions with AS 690 before April 21, 1995. On April 21, 1995 at 09:00 EDT, Merit will terminate peering sessions with all organizations still attached to the NSFNET Backbone service. The goal of this action is to identify where there are pockets of unreachable destinations. At the NSFNET Executive Committee meeting which took place on April 12, 1995, the committee expressed concern over the large amount of traffic still traversing the NSFNET service. Based on this concern, the committee requested that Merit take the actions described in this message. If an organization identifies a reachability problem between April 21 and April 28, it should send a message to merit-ie(a)merit.edu. We will work with the organization to resolve the problem and will reestablish temporary access to the NSFNET service as necessary. On April 28, 1995, all sessions with the NSFNET service will be permanently terminated and ANS will terminate operation of the NSFNET Backbone service on April 30, 1995. The following locations where access to the NSFNET service is provided will be impacted by this discontinuation of service on April 21, 1995: Ann Arbor, MI Argonne, IL Boston, MA Boulder, CO Champaign, IL College Park, MD (FIX-East) Houston, TX Ithaca, NY Lincoln, NE Palo Alto, CA Pittsburgh, PA Princeton, NJ Salt Lake City, UT Seattle, WA San Diego, CA Please send any questions regarding this plan to merit-ie(a)merit.edu. Thank you. --Elise Gerich Manager, Internet Engineers Merit Network Inc.

2 2

SNMP vs 1.1.1.1 (fwd)
by Michael Dillon 18 Apr '95

18 Apr '95

I mentioned some of the thread re: 1.1.1.1 on portmaster-users because there seemed to be an implication that Livingston's Portmaster had a problem in its PPP implementation. Now I get a question that I don't know enough to answer. Perhaps one of you could help this fellow.... ---------- Forwarded message ---------- Date: Mon, 17 Apr 95 21:37:38 CDT From: Kevin Sears x3-5160 <searsk(a)iscmed.med.ge.com> To: portmaster-users(a)msen.com Subject: SNMP vs 1.1.1.1 Greetings, What does SNMP and IP address 1.1.1.1 have in common(seen a few postings on this topic tonight wrt Ascend ISDN routers and Netmanage's Chameleon)? I had a Sniffer on my 3.x.x.x subnet looking for a Portmaster problem when I noticed that I was getting SNMP get next requests from a device in another part of GE directed to my Portmaster on subnet 3.x.x.x with an address of 1.1.1.1. My portmaster's ethernet address was in that packet(i.e. 1.1.1.1) so I'm surprised. What gives? ============================== Kevin Sears Systems & Network Support Tech OnLine Center GE Medical Systems PO Box 414, m/s-W595 Milwaukee, WI 53201 Internet: searsk(a)med.ge.com Voice: 414-524-5160 FAX: 414-524-5305

2 1

Re: Has PSI been assigned network 1?
by Steven J. Richardson 18 Apr '95

18 Apr '95

>From list-admin(a)merit.edu Tue Apr 18 03:33:58 1995 >Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.6.12/merit-2.0) with ESMTP id DAA02559; Tue, 18 Apr 1995 03:33:55 -0400 >Received: from VM.TAU.AC.IL (taunivm.tau.ac.il [132.66.32.4]) by merit.edu (8.6.10/merit-2.0) with SMTP id DAA01097 for <nanog(a)MERIT.EDU>; Tue, 18 Apr 1995 03:16:12 -0400 >Message-Id: <199504180716.DAA01097(a)merit.edu> >Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R1) > with BSMTP id 4716; Tue, 18 Apr 95 10:17:42 IST >Received: from VM.TAU.AC.IL (NJE origin HANK@TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 4461; Tue, 18 Apr 1995 10:17:42 +0200 >Date: Tue, 18 Apr 95 10:13:35 IST >From: Hank Nussbacher <HANK(a)taunivm.tau.ac.il> >Subject: Re: Has PSI been assigned network 1? >To: Curtis Villamizar <curtis(a)ans.net> >cc: Peter Lothberg <roll(a)stupi.se>, nanog(a)merit.edu >In-Reply-To: Message of Mon, 17 Apr 1995 12:00:24 -0400 from <curtis(a)ans.net> >MIME-Version: 1.0 >Content-Type: Text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7BIT >Status: R > >On Mon, 17 Apr 1995 12:00:24 -0400 you said: >>Curtis >> >>BTW- You might try a traceroute to an address in 140.222/16. That's >>the ANS backbone. For example, traceroute 140.222.32.62 would verify >>that you could reach ANS NY POP. Traceroute 140.222.1.1 would give >>you a !H as soon as you reach an ANS interface (look for t3.ans.net in >>the DNS if the response is not from a 140.222 address). > >Will 140.222.0.0 continue to work? We 'ip default-network 140.222.0.0' >and will have to change if this NSFnet backbone net ceases to exist. AS 690 = NSFNET/ANSnet backbone AS, with backbone net 140.222/16 Just because NSFNET is going away doesn't mean that ANSnet is disappearing; "reports of [its] death are extremely exaggerated"... ;-) Steve Richardson/Merit >I would bet lots of smaller ISPs have this net out there in their >routing tables as gateway of last resort. > >Thanks, >+---------------------------------------------------------------+ >| Hank Nussbacher | >| Inter-University Computer Center IBM | >| Tel-Aviv University Rechov Weizmann 2 >| Ramat Aviv ISRAEL Tel Aviv ISRAEL | >| | >| Work phone: +972-3-6408309 Work phone: +972-3-6978852 | >| Work fax: +972-3-6409118 | >| Home phone: +972-9-920165 | >| Home fax: +972-9-920166 | >| | >| Internet: hank(a)vm.tau.ac.il or hankn(a)vnet.ibm.com | >| | >| Crash dummy of the Israeli Information Highway | >+---------------------------------------------------------------+

1 0

Re: Has PSI been assigned network 1?
by Hank Nussbacher 18 Apr '95

18 Apr '95

On Mon, 17 Apr 1995 12:00:24 -0400 you said: >Curtis > >BTW- You might try a traceroute to an address in 140.222/16. That's >the ANS backbone. For example, traceroute 140.222.32.62 would verify >that you could reach ANS NY POP. Traceroute 140.222.1.1 would give >you a !H as soon as you reach an ANS interface (look for t3.ans.net in >the DNS if the response is not from a 140.222 address). Will 140.222.0.0 continue to work? We 'ip default-network 140.222.0.0' and will have to change if this NSFnet backbone net ceases to exist. I would bet lots of smaller ISPs have this net out there in their routing tables as gateway of last resort. Thanks, +---------------------------------------------------------------+ | Hank Nussbacher | | Inter-University Computer Center IBM | | Tel-Aviv University Rechov Weizmann 2 | Ramat Aviv ISRAEL Tel Aviv ISRAEL | | | | Work phone: +972-3-6408309 Work phone: +972-3-6978852 | | Work fax: +972-3-6409118 | | Home phone: +972-9-920165 | | Home fax: +972-9-920166 | | | | Internet: hank(a)vm.tau.ac.il or hankn(a)vnet.ibm.com | | | | Crash dummy of the Israeli Information Highway | +---------------------------------------------------------------+

1 0

Re: Has PSI been assigned network 1?
by Dave Morton 18 Apr '95

18 Apr '95

>>BTW- You might try a traceroute to an address in 140.222/16. That's >>the ANS backbone. For example, traceroute 140.222.32.62 would verify >>that you could reach ANS NY POP. Traceroute 140.222.1.1 would give >>you a !H as soon as you reach an ANS interface (look for t3.ans.net in >>the DNS if the response is not from a 140.222 address). > >Will 140.222.0.0 continue to work? We 'ip default-network 140.222.0.0' >and will have to change if this NSFnet backbone net ceases to exist. >I would bet lots of smaller ISPs have this net out there in their >routing tables as gateway of last resort. > >Thanks, Hank, why don't you just default to EBONE as we do ? Dave

1 0