April 1995 - Test - lists.nanog.org

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

Re: Final transition steps
by Sean Doran 17 Apr '95

17 Apr '95

Um, are these April 21 disconnections going to be permanent, or is this just a test of limited duration (six or seven hours, say)? If the turn-off is going to last a long time then the NSFNET International Connectivity Project will need MERIT to process and have installed, no later than this Wednesday, a NACR with changes to about 16000 prefixes. We can prepare the NACR this weekend. We will also need to know whether this is a full turn-off of the NSFNET backbone service next Friday as it will affect our immediate plans for turning up an ICM DS3 connection to MAE-EAST+, effectively moving the timing of that forward a few days. (To get the ICM DS3 up and running on time for the 21st (instead of before the 30th) we have some timing issues that are pretty critical, namely provisioning the DS3 and installing all the equipment. It is unclear that this is possible on the MFS side (never mind the paperwork process, which we probably will just have to ignore in the short run). What is clear though is that current connectivity to MAE-EAST is insufficient for making 21 April a happy day -- ICM is transiting SprintLink's (too full) DS3 to MAE-EAST, and using the FIX to reach the fednets and the networks which have not yet transitioned; the current DS3 can't support moving 10Mbps from the FIX, and don't even mention the ethernet that ICM still has today). I am not opposed to the idea, nor to the implementation of this push towards finding alternate connectivity. However, I'm pretty annoyed that we got very short notice of what appears to be an early shutdown of the NSFNET backbone service. This is especially irritating as a shutdown on the 21st will dramatically affect routing worldwide, and force a rewrite of a number of transition schedules which have been in place for quite some time. However, let's run with it. We'll know early in the week when Peter, Vadim and I have spent alot more time on moving ICM transition forward how bad things will be at 9am on the 21st as opposed to the evening of the 26th, and then again late at night on the 30th. Right now, I humbly request that MERIT wearing its RA hat quickly (i.e., this weekend, and certainly no later than Wednesday morning) locates an RS at FIX-EAST so that ICM can more rapidly bring up safe peering with the FIX-EAST connectees than we had initially planned (i.e., we need to have functional peering and transit set up this week instead of using this week to debug things with the fednets who are facing disconnectivity as of the 30th). This RS should be seeded from the ENSS145 configurations rather than any other source. Having something in place at FIX-EAST which does the same filtering that the AS 690 PRDB mechanism did has now been made much more urgent than it was yesterday, so that we can avoid rushing direct peerings, which traditionally has resulted in serious routing botches that the whole world notices. Sean. - -- Sean Doran <smd(a)icm1.icp.net>

3 2

Re: Final transition steps
by Elise Gerich 17 Apr '95

17 Apr '95

Push, The following peering sessions will be unaffected: PacBell NAP ----------- CRL AS 2041 Net99 AS 4388 Route server AS 2882 ANS AS 1321 AS 1688 ANS CIX AS 1957 Sprint NAP ---------- Sprintlink AS 1239 CERFnet AS 1740 Route server AS 2884 Test-RS AS 2886 networkMCI AS 3561 MAE-East -------- Netcomm AS 2551 Route server AS 2885 Interpath AS 3407 networkMCI AS 3561 Net99 AS 3830 B3net AS 4136 Alternet AS 701 Sprintlink AS 1239 CERN/Dante AS 1674 PIPEX AS 1849 Europe RS AS 1879 PSI AS 2149 AADS NAP -------- networkMCI AS 3561 AADS AS 3421 ANS AS 1323 AS 1688 FIX-West -------- NASA AS 297 AS 372 ESnet AS 293 AS 3429 DREN AS 668 DSI AS 2699 Milnet AS 568 network MCI AS 3561 NASA-test AS 1263 Sprintlink AS 1239 Anyone wishing to peer with ANS post-April 30 should contact ANS directly. --Elise >Pushpendra Mohta writes: > > > Sorry- Last nagging question. AS1740 has a AS690 peer at the NY NAP. > Since I dont see the NY NAP ENSS on this list, should I assume > that that peering wont be affected ? > > > > Elise Gerich writes: > > > > >Pushpendra Mohta writes: > > > > > > Elise > > > > > > Will this apply to the peers at the NAPs ? The New York NAP > > > in particular ? > > > > > > --pushpendra > > > > > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > > > Director, CERFnet http://www.cerf.net +1 800 876 2373 > > > > > > > To better clarify which Autonomous Systems will be effected by the > > April 21, 1995 action, here is a list of the NSFNET Backbone Service > > nodes and the associated Autonomous Systems that are proposed to be > > effected. Due to some information that we have received from one > > or two organizations, this list may be modified. > > > > --Elise > > > > City ENSS# Associated AS# > > -------------------------------------------------------------------------------- > > Ann Arbor, MI 131 237 MICHnet > > 1225 CICnet > > > > Argonne, IL 130 683 Argonne > > 1225 CICnet > > > > Boston, MA 134 560 NEARnet > > 701 Alternet > > > > Boulder, CO 141 58 Los Alamos > > 278 MexNet > > 297 NASA > > 2648 NIST > > > > Champaign, IL 129 38 UIUC > > 555 MSC > > 698 UIRnet > > 1224 NCSA > > 1225 CICnet > > > > College Park, MD > > (FIX-East) 145 293 ESnet > > 297 NASA > > 568 Milnet > > 668 DREN > > 699 DSI > > 1800 ICM > > > > Houston, TX 139 114 Sesquinet > > 297 NASA > > 3354 THEnet > > > > Ithaca, NY 133 174 PSI/NYSERnet > > 133 gated testing > > > > Lincoln, NE 140 93 MIDnet > > > > Palo Alto, CA 128 199 BARRnet > > 200 BARRnet > > > > Pittsburgh, PA 132 204 PSCnet > > 1206 PSCnet > > 3577 Prepnet > > > > Princeton, NJ 137 97 GES/Jvncnet > > 1250 Princeton > > > > Salt Lake City,UT 142 210 Westnet > > > > Seattle, WA 143 685 NorthWestNet > > 73 NorthWestNet > > > > San Diego, CA 135 195 SDSC > > 1740 CERFnet > > 1838 CERFnet > > 2150 CSUnet > > 22 NOSC > > > > NASA Ames, CA 144 200 BARRnet > > > > > > --pushpendra > > Pushpendra Mohta pushp(a)cerf.net +1 619 455 3908 > Director, CERFnet http://www.cerf.net +1 800 876 2373 > >

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 17 Apr '95

17 Apr '95

Well, you can always do filtering of routing updates at your ciscos. If i understand correctly Ascends are not directly connected to MAE-East. --vadim 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

1 0